Application of PWE3 to MPLS Transport Networks draft-bryant-pwe3-mpls-transport-00 {stbryant,mmorrow,tnadeau,swallow}@cisco.com cherukuri@juniper.net

Background For some time ITU SG15 has been working on the design of a mechanism to provide an MPLS server layer for use in the construction of transport networks. (A transport network is the network that IETF thinks of as the physical network, i.e. Ethernet, SONET rings etc) The ITU proposal is to provide multi-layer virtualization of the transport network through the use of pseudowires and MPLS label stacking. This mechanism is known as T-MPLS (Transport MPLS)

Liaison, Interims and Plenary ITU SG15 liaised their design to the IETF very late in the standardisation process – specifically after the design completed it’s main approval state. There were a number of liaison statements that passed between the IETF and ITU SG15, two interim meetings and an ITU SG15 plenary that is currently underway. The Interims and Plenary were variously attended by both MPLS WG chairs, one of the PWE3 WG chairs, one CCAMP chair and one of the routing ADs. As a result of these discussions a number of violations of invariants in the MPLS architecture were identified and corrected. The phase 1 T-MPLS design will go for final consent this Friday, and final consent is almost certain.

Fundamental Concern T-MPLS has been described in various ITU meetings as a sub-set of PWE3 + MPLS and as an extended subset. Although other groups have cast the PWE3 + MPLS design in there own language, these groups have always worked very closely with the IETF at all stages, and both the intent and the outcome has always been bit-for-bit semantic compatibility. (I.e., there have been no extensions or variations). T-MPLS uses the same Ethertypes as MPLS/PWE3. The fundamental concern therefore is that the T-MPLS variant of pseudowire over MPLS will in some way, and at some time, depart from the IETF design without any way for the network to know which variant it is operating.

Purpose of this draft Prior to the IETF involvement no attempt had been made to document the transport MPLS requirements. At one of the interim meeting, SG15 Q12 were persuaded to document the transport MPLS requirements, and these were liaised to the IETF. The purpose of this draft is to describe how those requirements can be met using existing IETF RFCs without modification.

Key Requirements No merging No PHP The PHP requirement derives from the OAM desired on the PSN tunnel (there is no PHP on the PWE3 label). Bidirectional & unidirectional pt-pt with reciprocal paths. Unidirectional multi-point paths. Ability to operate without IP in the network. Configuration may be via an external NMS. Phase 1 requirements restricted to pt-pt Ethernet PWs

Application PWE3 to MPLS Transport Networks IP/MPLS PSN (PHP may be enabled) MPLS PSN (No PHP) 802.3 802.3 CE1 PE1 PE2 CE2 MPLS PSN (no PHP) Pseudowire 802.3 (Ethernet) IP/MPLS LSP (PHP may be supported)

PWE3 Configuration Encapsulation is Ethernet [RFC4448], used in "raw" mode. The Control Word MUST be used. The Sequence number MUST be zero. Pseudowire Label is statically provisioned. Pseudowire Setup and Maintenance Label Distribution Protocol [RFC4447] is not supported.

PW OAM The OAM mechanism is VCCV [VCCV]. One of the following VCCV profiles MUST be used: BFD without IP/UDP Headers BFD with IP/UDP Headers

VCCV profile 1: BFD without IP/UDP Headers The first nibble is set to 0001b to indicate a pseudowire associated channel. The Version and the Reserved fields are set to 0, the Version is 0. Channel Type is set to 0x07 to indicate that the payload carried in BFD without IP/UDP headers The connection verification method used by VCCV is BFD with diagnostics as defined in 4.1

VCCV profile 2: BFD with IP/UDP Headers May be used when the PEs are IP capable and have been configured with IP addresses. The first nibble is set to 0001b to indicate a pseudowire associated channel. The Version and the Reserved fields are set to 0, the Version is 0. The Channel Type is set to 0x21 for IPv4 and 0x56 for IPv6 payloads. The connection verification method used by VCCV is BFD with diagnostics as defined in 4.1 of [VCCV].

MPLS Configuration The profile considers two cases: The case where external configuration is used The case where a control plane is available

External MPLS Configuration All MPLS labels MUST be statically provisioned. Labels may be selected from the per-platform or per-interface label space. All LSPs MUST support both unidirectional and bi-directional point-to-point connections. LSPs SHOULD support unidirectional point-to-multipoint connections. The forward and backward directions of a bi-directional connection should follow the same path along the transport LSP. Equal cost multi-path (ECMP) load balancing MUST NOT be configured . The Merging of label switched paths is prohibited and MUST NOT be configured. Penultimate hop popping by the LSRs MUST be disabled . Both E-LSP and L-LSP MUST be supported. The MPLS EXP field is supported according to RFC3270 for only when the pipe and short-pipe models are utilized.

Control Plane MPLS Configuration Profile applies when RSVP-TE or the bi-directional support in GMPLS are used to configure the MPLS PSN The following are automatically provided: There is no label merging unless it is deliberately enabled to support Fast Re-route (FRR). A single path is provided end-to-end (There is no ECMP). Paths may be unidirectional or bidirectional as required. The following configurations restrictions MUST be applied: Penultimate hop popping by the LSRs MUST be disabled. Both E-LSP and L-LSP MUST be supported. The MPLS EXP field is supported according to RFC3270 for only when the pipe and short-pipe models are utilized.

MPLS OAM The draft needs more work to specify the MPLS OAM. Note that the requirement is that this OAM be able to operate without the use of IP.

Next Steps Please read the draft and the liaisons, particularly the requirements for the use of MPLS in transport networks. The PWE3 WG needs to consider what it wishes to do next: Do we wish to adopt this topic as a WG item? Is this draft a suitable starting point? Do we wish to adopt this draft? Do we liaise this draft to ITU SG15 Q12?