applicability of generalized multiprotocol label switching
TRANSCRIPT
CCAMP WG, IETF 80th, Prague, Czech Republic
draft-zhang-ccamp-gmpls-uni-app-01.txt
Applicability of Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI)
Fatai Zhang <[email protected]> Oscar Gonzalez de Dios <[email protected]>
Daniele Ceccarelli <[email protected]>
Greg M. Bernstein <[email protected]>
Adrian Farrel <[email protected]>
Overview of this Draft
– UNI Deployment in different addressing space scenarios – UNI Deployment in different addressing space scenarios – UNI TE link discovery – 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
UNI Address Space�
• Existing GMPLS UNI• Existing GMPLS UNI: ENs and their attached : ENs and their attached CNs MUST share the same CNs MUST share the same address space
– <EN1, CN1>, <EN2, CN2>, <EN3, CN3> 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 • It may need to lift-up this address space restriction and introduce some process or mechanisms some process or mechanisms
– e.g., address mapping – e.g., reuse the session shuffling model defined in L1VPN (see the later slide…)�defined in L1VPN (see the later slide…)�
GMPLS UNI EN1 CN1 EN2 CN2
EN3
CN3
CN4
GMPLS UNI
CN5 Overlay Network
Overlay Network
Overlay Network
Core Network
GMPLS UNI
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 �
EN1 CN1 EN2
CN2
EN3
CN3
CN4
CN5 Overlay Network
Overlay Network
Overlay Network
Core Network EN1-CN1 Link_ID
EN2-CN2 Link_ID
EN3-CN3 Link_ID
EN1-CN1 Link_ID EN2-CN2 Link_ID EN3-CN3 Link_ID
Path (Dest = EN2)
EN2 <-> CN2 Path (Dest = EN2) Path (Dest = EN2)
UNI Path Computation�
EN1 CN1 EN2 CN2 CN3 CN4
CN5
PCE
Path
Computing: CN1-CN5-CN2 • CN1 or PCE computes the
path segment inside the core network
• No need to select source UNI link because of single-homing
• PCE is aware of ENs and is visible to ENs • PCE computes the E2E optimal path (by
selecting the source UNI TE link)
EN1
EN2
PCE
CN1 CN2
CN3 CN4
CN5 EN1
EN2
PCE B
CN1 CN2
CN3 CN4
CN5
Single-homing:
Request: EN1-EN2
EN1-CN3-CN4-EN2
PCE A BRPC
EN1-EN2 EN1-CN3-CN4-EN2
• PCE A for the overlay network • PCE B for the core network • BRPC between PCE A and PCE B for UNI
path computation
Multi-homing:
Note: No PCEP extensions are needed, just need some descriptions on how to deploy PCE in the UNI scenarios.
UNI Conn Provisioning Models�
CN1 CN3 CN2 EN1 EN2
Core Network
End-to-end RSVP Session
CN1 CN3 CN2 EN1 EN2
Core Network
S-LSP
CN1 CN3 CN2 EN1 EN2
Core Network
Address mapping
EN1 EN2
Core Network
H-LSP
CN1 CN3 CN2
End-to-end RSVP Session
End-to-end RSVP Session End-to-end RSVP Session
• Single end-to-end session through ENs and CNs • Similar to intra domain path provisioning
• S-LSP is pre-provisioned • Stitch the UNI connection to the created S-LSP
• 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
• 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
Flat model [RFC3473] Stitching model [RFC5150]
Session Shuffling model [RFC5251] Hierarchical model [RFC6107][4206]
End-to-end UNI Path Recovery�
CN1 CN2 CN3
EN1 EN2 Core Network
CN4 CN5 CN6
PCE
• In the case that PCE is involved: - Path Key can be used for confidentiality consideration
EN1-EN2 PKS_W EN1-EN2, exclude
PKS_W PKS_P
CN1 CN2 CN3
EN1 EN2 Core Network
CN4 CN5 CN6
PCE
EN1-EN2 1+1
PKS_W & PKS_P
Serial Path Computation
Concurrent Path Computation
W
P
W
P
End-to-end UNI Path Recovery�
CN1 CN2 CN3
EN1 EN2 Core Network
CN4 CN5 CN6
(1) Using RRO to collect the working path information
(2) Using XRO to exclude the working path when creating the protection path
CN1 CN2 CN3
EN1 EN2 Core Network
CN4 CN5 CN6
(1) Collect the working path SRLG
(2) Exclude the SRLG when creating the protection path
General method
Topology hidden (confidentiality consideration)
Key point: diversity between working and protection path
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�
CN2 CN3 CN4
Core Network
CN5 CN6 CN7
EN1 EN2
CN1 CN8
Branch node Merge node
From the perspective of E2E and EN, this scenario is Segment recovery, but it can not control it explicitly.
UNI Call�
EN1
CN1
EN2
CN2
CN3 CN4 Overlay Network
Overlay Network
Core Network
UNI Call - Exchange of UNI link information
EN1 EN2
CallM 1 CallM 2
CallM 3 CallM 4 CallM 5
Domain 1 Domain 2
Domain 3 Domain 4 Domain 5
Call ERO = 1,2 Call ERO = 2
Call
• Exchanging of UNI link information [RFC4974]: • Information of destination UNI link is not advertised to the source EN.
Therefore, Call is needed
• 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)
CallM: Call Manager
UNI Multicast�UNI Multicast�• There is a requirement to transport signals from one EN to multiple ENs • There is a requirement to transport signals from one EN to multiple ENs • If UNI P2MP connection is supported, bandwidth resource is saved • If UNI P2MP connection is supported, bandwidth resource is saved
• Requirements:
EN1 CN1 EN2 CN2
EN3 EN4
CN3
CN4
CN5
EN1 CN1 EN2 CN2
EN3 EN4
CN3
CN4
CN5
Case 1: client layer multicast (saving UNI resource)
Case 2: server layer multicast (saving UNI & core network resource)
E.g., packet over TDM network, and CN1 has the packet multicast capability
E.g., all the nodes involved can support multicast capability
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)
Next Steps
– Request the comments from operators • Any other scenarios should be included?
– Any comments are always appreciated