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 <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>

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

UNI Address Space

• 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 UNIEN1 CN1 EN2CN2

EN3

CN3

CN4

GMPLS UNI

CN5Overlay 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

CN5Overlay Network

Overlay Network

Overlay Network

Core NetworkEN1-CN1Link_ID

EN2-CN2Link_ID

EN3-CN3Link_ID

EN1-CN1 Link_IDEN2-CN2 Link_IDEN3-CN3 Link_ID

Path (Dest = EN2)

EN2 <-> CN2 Path (Dest = EN2)

Path (Dest = EN2)

UNI Path Computation

EN1 CN1 EN2CN2CN3CN4

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

CN3CN4

CN5EN1

EN2

PCE B

CN1 CN2

CN3CN4

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 CN2EN1 EN2

Core Network

End-to-end RSVP Session

CN1 CN3 CN2EN1 EN2

Core Network

S-LSP

CN1 CN3 CN2EN1 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 EN2Core Network

CN4 CN5 CN6

PCE

• In the case that PCE is involved: Path Key can be used for confidentiality

consideration

EN1-EN2 PKS_WEN1-EN2,

exclude PKS_WPKS_P

CN1 CN2 CN3

EN1 EN2Core Network

CN4 CN5 CN6

PCE

EN1-EN2 1+1

PKS_W & PKS_P

Serial Path Computati

on

Concurrent Path

Computation

W

P

W

P

End-to-end UNI Path Recovery

CN1 CN2 CN3

EN1 EN2Core 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 EN2Core 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 CN4Overlay 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• 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

EN1 CN1 EN2CN2

EN3 EN4

CN3

CN4

CN5

EN1 CN1 EN2CN2

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