Applicability of Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI)

1. Applicability of Generalized Multiprotocol Label Switching (GMPLS)User-Network Interface (UNI) CCAMP WG, IETF 80th, Prague, Czech Republic draft-zhang-ccamp-gmpls-uni-app-01.txt Fatai Zhang <zhangfatai@huawei.com> Oscar Gonzalez de Dios <ogondio@tid.es> • Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> • Greg M. Bernstein <gregb@grotto-networking.com> • Adrian Farrel <adrian@olddog.co.uk>

2. Overview of this Draft • Examines a number of GMPLS UNI [RFC4208] app scenarios • UNI Deployment in different addressing space scenarios • UNI TE link discovery • UNI path computation • UNI connection provisioning models • UNI path recovery • UNI Call • UNI multicast • Shows how GMPLS protocol and PCE can be used to automate or enable critical processes for these applications • Points out some existing unresolved issues of GMPLS UNI and suggests simple extensions to existing technologies to resolve the issues

3. UNI Address Space EN3 Overlay Network • Existing GMPLS UNI: ENs and their attached CNs MUST share the same address space • <EN1, CN1>, <EN2, CN2>, <EN3, CN3> MUST share the same address space • Practical deployment: ENs and CNs may belong to different carriers and may NOT share the same address space • E.g., ENs use IPv4 while CNs use IPv6, or, CNs and ENs use overlapping address • It may need to lift-up this address space restriction and introduce some process or mechanisms • e.g., address mapping • e.g., reuse the session shuffling model defined in L1VPN (see the later slide…) GMPLS UNI CN4 GMPLS UNI CN1 CN2 EN1 GMPLS UNI EN2 CN3 Overlay Network Overlay Network CN5 Core Network

4. UNI TE Link Discovery • When creating UNI connection, ingress CN is responsible to resolve who is the egress CN that the destination EN is attached • i.e., CNs should learn the information of all EN-CN relationship(e.g., by discovery or manual configuation) • IGP needs to advertise the EN-CN relationship inside the core network • L1VPN scenario: using L1VPN LSA [RFC5252] to advertise the CE-PE link • It could be possible to generalize this LSA to support other UNI scenarios Overlay Network EN3 EN1-CN1 Link_ID EN2-CN2 Link_ID EN3-CN3 Link_ID EN3-CN3 Link_ID EN2-CN2 Link_ID CN4 EN1 CN1 EN2 CN3 Overlay Network Overlay Network CN5 CN2 EN1-CN1 Link_ID Core Network Path (Dest = EN2) Path (Dest = EN2) EN2 <-> CN2 Path (Dest = EN2)

5. UNI Path Computation Single-homing: Computing: CN1-CN5-CN2 PCE • CN1 or PCE computes the path segment inside the core network • No need to select source UNI link because of single-homing CN4 CN1 CN2 EN1 EN2 CN3 CN5 Path Multi-homing: Request: EN1-EN2 PCE A PCE B BRPC PCE EN1-CN3-CN4-EN2 EN1-CN3-CN4-EN2 CN4 EN1-EN2 CN4 CN3 CN3 EN2 EN2 CN5 CN5 EN1 EN1 CN1 CN2 CN1 CN2 • PCE A for the overlay network • PCE B for the core network • BRPCbetween PCE A and PCE B for UNI path computation • PCE is aware of ENs and is visible to ENs • PCE computes the E2E optimal path (by selecting the source UNI TE link) Note: No PCEP extensions are needed, just need some descriptions on how to deploy PCE in the UNI scenarios.

6. UNI Conn Provisioning Models Flat model [RFC3473] Stitching model [RFC5150] Core Network Core Network EN1 CN1 CN3 CN2 EN2 EN1 CN1 CN3 CN2 EN2 S-LSP End-to-end RSVP Session End-to-end RSVP Session • S-LSP is pre-provisioned • Stitch the UNI connection to the created S-LSP • Single end-to-end session through ENs and CNs • Similar to intra domain path provisioning Session Shuffling model [RFC5251] Hierarchical model [RFC6107][4206] Core Network Core Network CN2 CN1 CN3 EN1 CN1 CN3 CN2 EN2 EN1 EN2 Address mapping H-LSP End-to-end RSVP Session End-to-end RSVP Session • The end-to-end UNI connection is nested into the H-LSP (tunnel) • H-LSP can pre-provisioned or be triggered by the UNI signaling • Address mapping at ingress/egress CNs, which changes the session identifiers • End-to-end session: source / dest = EN1 / EN2 • Core session: source / dest = CN1 / CN2

7. End-to-end UNI Path Recovery • In the case that PCE is involved: • Path Key can be used for confidentiality consideration PCE EN1-EN2 PKS_W EN1-EN2, exclude PKS_W PKS_P Serial Path Computation CN1 CN2 CN3 W EN1 EN2 Core Network CN4 CN5 CN6 P PCE EN1-EN2 1+1 PKS_W & PKS_P Concurrent Path Computation CN1 CN2 CN3 W EN1 EN2 Core Network CN4 CN5 CN6 P

8. End-to-end UNI Path Recovery Key point: diversity between working and protection path (1) Using RRO to collect the working path information CN1 CN2 CN3 General method EN1 EN2 Core Network CN4 CN5 CN6 (2) Using XRO to exclude the working path when creating the protection path (1) Collect the working path SRLG Topology hidden (confidentiality consideration) CN1 CN2 CN3 EN1 EN2 Core Network CN4 CN5 CN6 (2) Exclude the SRLG when creating the protection path

9. UNI Segment Recovery • [RFC4873] provides the segment recovery • Use SERO to indicate the recovery segment between the branch node and the merge node • But in UNI cases, the source EN may not know which CN the destination EN is attached to • Therefore, source EN cannot control the segment recovery explicitly (i.e., it can not fill the address of merge node into the SERO) • This issue may need to be address From the perspective of E2E and EN, this scenario is Segment recovery, but it can not control it explicitly. Core Network CN2 CN3 CN4 CN8 CN1 EN1 EN2 CN5 CN6 CN7 Branch node Merge node

10. UNI Call • Exchanging of UNI link information [RFC4974]: • Information of destination UNI link is not advertised to the source EN. Therefore, Call is needed UNI Call - Exchange of UNI link information EN1 EN2 CN4 CN3 Overlay Network Overlay Network CN1 CN2 Core Network • Multi-domain Scenarios: • Commercial and policy motivations play an important role in selecting Call route • Explicit of Call control is required (i.e., it may need some extensions) Call ERO = 2 CallM 1 CallM 2 Call ERO = 1,2 Call Domain 1 Domain 2 EN1 EN2 CallM 3 CallM 5 CallM 4 Domain 3 Domain 4 Domain 5 CallM: Call Manager

11. UNI Multicast • There is a requirement to transport signals from one EN to multiple ENs • If UNI P2MP connection is supported, bandwidth resource is saved • Requirements: UNI support the P2MP signaling Case 1: client layer multicast (saving UNI resource) E.g., packet over TDM network, and CN1 has the packet multicast capability EN3 EN4 CN4 CN1 CN2 EN2 EN1 CN3 CN5 Case 2: server layer multicast (saving UNI & core network resource) EN3 EN4 E.g., all the nodes involved can support multicast capability CN4 CN1 CN2 EN2 EN1 CN3 CN5

12. Conclusions • The existing tools including GMPLS, PCE and GMPLS UNI [RFC4208] can support most of the scenarios • There still are some restrictions or gaps to be resolved • E.g., address space restriction, UNI link discovery, UNI path provisioning, UNI recovery, UNI Call… • Enhancement to the GMPLS UNI is required • Some extensions to the existing tools (e.g., GMPLS, UNI, PCE)

13. Next Steps • Request the comments from operators • Any other scenarios should be included? • Any comments are always appreciated