Interoperability in and Management of a Multi-Technology Packet Transport Network

1. Interoperability in and Management of a Multi-Technology Packet Transport Network Maarten Vissers Version 0.0

2. Introduction • Our industry has developed three packet transport network technologies to support transport of frame/packet based service signals as well as bit stream based service signals and created as such a Multi-Technology PTN Customer Networks Customer Network Customer Network Customer Network Multi-TechnologyPacket Transport Network PTNNMS

3. PTN Technologies • Ethernet and MPLS packet technologies are extended with a Transport Profile (TP) • MPLS is extended with a single transport profile, Ethernet is extended with two transport profiles (with different tunnel layer technologies: VLAN and MAC) • The layer stacks for those three PTN technologies are very similar and management of these PTN variations can be unified under a single PTN Network Manager MPLS-TP Ethernet-TP (I) Ethernet-TP (II) Customer/Client Customer/Client Customer/Client MPLS PW Service VLAN Service VLAN Service VLAN (VPLS) MPLS Tunnel Tunnel VLAN Tunnel MAC MPLS Link Link VLAN Link VLAN Physical Media(802.3,G.707,G.709) Physical Media(802.3,G.707,G.709) Physical Media(802.3,G.707,G.709)

4. PTN Layer Stack & Unified Network Management PTNNMS ACCESS METRO CORE METRO Metro Aggr. Metro Edge NTUMTU Metro Aggr. Metro Core Outer Core Inner Core Outer Core Metro Core Metro Edge Customer/Client layer PTN Service (Channel) layer PTN Tunnel (Path) layer Link (Section) layer Physical Media GFP Physical Media Physical Media GFP GFP GFP GFP Physical Media Physical Media Physical Media Physical Media Physical Media Physical Media

5. Services in Multi-Technology PTN • Carrier packet transport networks consists typically of access, metro and core domains • Access domains typically deploy Ethernet, metro domains deploy Ethernet or MPLS and core domains deploy MPLS technologies today • The evolution of those packet network technologies into packet transport network technologies is ongoing for some time • In the near future all three PTN technologies will have the same capabilities and there is no reason for carriers to deploy a single technology and thus replace existing equipment • All three PTN technologies can be deployed in every domain (access, metro, core) • Those multi-technology PTN’s must support inter-domain LINE, TREE and LAN services, which requires interoperability between the three PTN technologies as endpoints of each service may be in different PTN technology domains • Such interoperability is required between the service (channel) layers in the three technologies; interoperability between tunnel (path) and link (section) layers in the three technologies is not required

6. PTN Interoperability for E-TREE/E-LAN services • All three PTN technologies deploy a service VLAN to support E-TREE and E-LAN services • Interoperability for those services is as such guaranteed; main difference is the tag/label used to identify each service VLAN • MPLS-TP: PW label, Ethernet-TP (I): VID, Ethernet-TP (II): SID Ethernet-TP (I) Ethernet-TP (II) MPLS-TP UNI UNI Customer/Client: TREE or LAN service rmp or mp2mp service VLAN (VPLS) VID SID PW label p2p tunnel VLAN p2p tunnel MAC p2p MPLS tunnel

7. PTN Interoperability for LINE/TREE services • Two out of three PTN technologies deploy a service VLAN to support LINE and TREE services, one technology deploys MS-PW • Interoperability for those services requires service VLAN to MS-PW interworking (as per clause 5.5/G.805 “layer network interworking”) • ETH/MPLS PW InterWorking function provides such interworking • Similar OAM PDU formats and similar client encapsulations make interworking trivial Ethernet-TP (I) Ethernet-TP (II) MPLS-TP UNI UNI Clause 5.5/G.805 Inter Working Function Customer/Client: LINE or TREE service p2p or p2mp PW p2p or p2mp service VLAN VID SID PW label p2p tunnel VLAN p2p tunnel MAC p2p MPLS tunnel

8. Clause 5.5/G.805 Layer Network Interworking • The objective of layer network interworking is to provide an end-to-end trail between different types of layer network trail terminations. This requires interworking of characteristic information as different layer networks have per definition different characteristic information. In general the adapted information of different layer networks for the same client layer network is also different, although this is not necessarily the case. Layer networking may therefore require the interworking of adapted information. • The trail overhead of a layer network can be defined in terms of semantics and syntax. Provided that the same semantics exist in two layer networks, the trail overhead can be interworked by passing on the semantics from one layer network to the other in the appropriate syntax, as defined by the characteristic information. In other words layer network interworking shall be transparent for the semantics of the trail overhead. If both layer networks have a different set of semantics, the layer network interworking is restricted to the common set of semantics. The layer network interworking function has to terminate (insert, supervise) the semantics that are not interworked. • Layer network interworking is accomplished through an interworking processing function as depicted in Figure 19. The interworking processing function supports an interworking link connection between two layer network connections. The interworking link connection is special in the sense that it is asymmetric, delimited by different types of ports. It is also special because it is in general, only transparent for a specified set of client layers. An interworking link is a topological component that represents a bridge between two layer networks. The interworking link creates a "super layer network", defined by the complete set of access groups that can be interworked for a specified set of client layer networks.

9. Example 1: TDM service • A TDM (e.g. 2 Mbit/s) LINE service is supported in Ethernet (MEF8) and MPLS (RFC4553). Both encapsulation methods are similar, which simplifies interworking of the adapted information. OAM interworking, see slide 11 ECID format is same as PW label format to ease interworking with MPLS according MEF8 ETH OAM MPLS-TP OAM E T H  P W Transmitted DA = Received SA or broadcast address Transmitted SA = local MAC address G.8021 ETH_AI Transmitted ECID = Received PW label stack entry Transmitted S-bit = Received ECID[23] DA SA MPLS-TP PW_AI 20 3 1 8 TYPE (88-d8) ID 000 1 00000010 ECID (fixed) S bit (1) CESoETH CW SAToP CW RTP (optional) RTP (optional) TDM payload TDM payload UNI UNI 2 Mbit/s (P12x_CI) service p2p MS-PW p2p service VLAN ETHPW ETH PW p2p tunnel VLAN p2p tunnel MAC p2p MPLS tunnel Ethernet-TP (I) Ethernet-TP (II) MPLS-TP

10. Example 2: E-LINE service • An Ethernet LINE service is supported in Ethernet and MPLS (RFC4558). Both encapsulation methods are similar, which simplifies interworking of the adapted information. OAM interworking, see slide 11 ETH OAM MPLS-TP OAM E T H  P W Transmitted S-bit = 1 Required in MPLS-TP MS-PW due to MPLS-TP OAM presence; Seq Number support is not required; SN = fixed to 0 MPLS-TP PW_AI S bit (1) G.8021 ETH_AI CW (fixed to all-0’s) DA DA SA SA MSDU MSDU UNI UNI E-LINE (ETH_CI) service p2p MS-PW p2p service VLAN ETHPW ETH PW p2p tunnel VLAN p2p tunnel MAC p2p MPLS tunnel Ethernet-TP (I) Ethernet-TP (II) MPLS-TP

11. Example 1&2: ETH and MPLS-TP PW NCM OAM interworking • For Network Connection Monitoring (highest MEG level) it is necessary to interwork the OAM PDU Header and Payload fields. The Header fields for both technologies are known and interworking is illustrated in figure below. The Payload fields of the MPLS-TP OAM are not yet specified; if those are a copy of the ETH OAM PDU Payload fields, then interworking becomes trivial. Transmitted DA = multicast address or for LBM TargetMIP/MEP address MIP or MEP identifier for Loopback OAM G.8021 ETH_CI (OAM) Transmitted SA = local MAC address or for LBM OriginatingMEP address E T H  P W MPLS-TP PW_CI (OAM) DA SA S bit (1) OAM PDU independent Header OAM PDU independent Header TYPE (89-02) 0001 MEL (NCM: 7) 4-bit Version 5-bit Version Reserved Channel Type OpCode Flags To Be Defined (e.g. copy of ETH OAM) TLV Offset OAM PDU specific Payload OAM PDU specific Payload OAM specific EndTLV UNI UNI E-LINE (ETH_CI) service p2p PW p2p service VLAN ETHPW ETH PW NCM-MEG NCM-MEG NCM-MEG p2p tunnel VLAN p2p tunnel MAC p2p MPLS tunnel Ethernet-TP (I) Ethernet-TP (II) MPLS-TP

12. Example 1&2: ETH and MPLS-TP PW TCM OAM interworking • For Tandem Connection Monitoring (intermediate MEG level) it is necessary to interwork the OAM PDU Header and Payload fields. The Header fields for both technologies are known and interworking is illustrated in figure below. The difference with the NCM OAM is the presence of a Label_13 GAL header. G.8021 ETH_CI (OAM) E T H  P W MPLS-TP PW_CI (OAM) DA one GAL header for PW TCM SA Label_13 GAL TYPE (89-02) 0001 MEL (TCM: 1..6) 4-bit Version ACH 5-bit Version Reserved Channel Type OpCode Flags To Be Defined TLV Offset OAM specific EndTLV E-NNI UNI UNI E-LINE (ETH_CI) service p2p PW p2p service VLAN ETHPW ETH PW NCM-MEG NCM-MEG NCM-MEG ETH TCM-LSP TCM-MEG TCM-MEG p2p tunnel VLAN p2p tunnel MAC p2p MPLS tunnel Ethernet-TP (I) Ethernet-TP (II) MPLS-TP

13. Conclusion • Interworking between ETH_CI and MPLS-TP PW_CI is an example of G.805 Layer Network Interworking • The addition of ETH/MPLS-TP PW interworking functions at the boundaries of Ethernet-TP and MPLS-TP domains reduces PTN network management complexity and reduces also complexity of UNI-N ports in MPLS-TP equipment • Interworking of ETH_AI and MPLS-TP PW_AI is trivial (i.e. not complex) due to common encapsulation methods of client signals • Interworking between ETH_CI and MPLS-TP PW_CI will become trivial when MPLS-TP OAM re-uses as much as possible the Ethernet OAM PDU Payload formats • Re-use of Ethernet OAM PDU payload formats has the additional advantage that existing (Ethernet OAM) hardware, firmware and software can be re-used, making MPLS-TP OAM available quickly