Application of PWE3 to MPLS Transport Networks

1
Application of PWE3 to MPLS Transport Networks

• draft-bryant-pwe3-mpls-transport-00
• stbryant,mmorrow,tnadeau,swallow_at_cisco.com
• cherukuri_at_juniper.net

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

3
Liaison, Interims and Plenary

• ITU SG15 liaised their design to the IETF very
  late in the standardisation process
  specifically after the design completed its 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.

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

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

6
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

7
Application PWE3 to MPLS Transport Networks
IP/MPLS PSN (PHP may be enabled)
MPLS PSN (No PHP)
802.3
802.3
CE1
CE2
PE1
PE2
MPLS PSN (no PHP)
Pseudowire
802.3 (Ethernet)
IP/MPLS LSP (PHP may be supported)
8
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.

9
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

10
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

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

12
MPLS Configuration

• The profile considers two cases
• The case where external configuration is used
• The case where a control plane is available

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

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

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

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