Standardization Progress of Packet Transport Networks

    There are two leading Packet Transport Network (PTN) technologies: Provider Backbone Bridge Traffic Engineering (PBB-TE) and MPLS Transport Profile (MPLS-TP). The former adapts Ethernet technology to carrier-class transport networks, while the latter is developed from transport networks and Multiprotocol Label Switching (MPLS).

    PBB-TE is derived from Provider Backbone Bridge (PBB) technology. PBB-TE eliminates Media Access Control (MAC) address learning, spanning tree protocol and flooding. It has connection-oriented features and improved network scalability.

    MPLS-TP is a connection-oriented packet-switched technology capable of Traffic Engineering (TE) and managing network resource use. The MPLS-TP data forwarding plane is a subset of MPLS defined by the Internet Engineering Task Force (IETF). MPLS-TP has MPLS features, but also meets transport requirements. It has a reliable protection mechanism, improved Quality of Service (QoS), and enables scalable Operation Administration and Maintenance (OAM).

    In terms of industrialization, MPLS-TP has won more support from vendors and operators than PBB-TE; therefore, it is more likely to be deployed in large-scale future networks[1-4].

1 PBB-TE
PBB-TE (IEEE 802.1Qay) is based on PBB (IEEE 802.1ah), which is also called MAC-in-MAC. Based on MAC stacking technology, it encapsulates user MAC within the operator’s MAC, enhancing Ethernet scalability and service security by using double encapsulation to isolate user traffic. The critical part of PBB involves the introduction of a 24 bit Service Instance Tag (I-TAG) into the MAC-in-MAC encapsulation.

    PBB-TE provides Ethernet with connection-oriented forwarding, which enables service providers to offer dedicated Ethernet links and to guarantee performance. In other words, PBB-TE provides strict QoS for a Metro Ethernet. Certain traditional Ethernet functions such as MAC address learning, broadcasting, spanning tree protocol, and multicasting are eliminated. PBB-TE is therefore connection-oriented and avoids the flooding of broadcasting packets. This enables connection configuration through network management system or control protocols so that carrier class protection switching, OAM, QoS, and TE are achieved. 

    PBB-TE uses IEEE 802.1ag as the signaling protocol for PBB-TE tunneling, and continuously monitors tunnel states in the network. If the working tunnel fails, services are automatically transferred to a pre-established backup circuit. This increases network flexibility.

    IEEE approved the establishment and authorization application of the PBB-TE program, setting up the 802.1Qay task group in March 2007. The group began standardization of the PBB-TE (IEEE 802.1Qay) data plane in April 2007, and voted through 802.1Qay Draft 1.1 in January 2008. In January 2009, IEEE introduced the draft version of 802.1Qay D5.0 and promoters voted on it. IEEE 802.1Qay-2009 was officially released in August 2009.

    Although it has been officially released, IEEE 802.1Qay only specifies the end-to-end protection of Traffic Engineering Service Instance (TESI). In order to improve reliability and flexibility, several companies applied a PBB-TE segment protection program (a kind of local protection program) and, in a plenary session held in July 2008, debated whether local protection should be implemented in infrastructure or TESI.

    The conclusion of that session was to make infrastructure protection for available programs, and to make improvements of TESI local protection as later required. After a year-long discussion, application of the PBB-TE segment protection program (program number IEEE 802.1Qbf) was finally approved at the plenary session in July 2009. The 802.1 working group released the first draft of IEEE 802.1Qbf D0.0 and carried out the first vote in September 2009. The discussion at the plenary session held in November 2009 focused on overlapping protection groups.

 
    As for the PBB-TE control plane, two technologies are available for dynamically configuring PBB-TE tunnels: Provider Link State Bridging (PLSB) and Generalized Multiprotocol Label Switching (GMPLS). PLSB is 802.1aq under the specification process of the IEEE 802.1 working group, while GMPLS is a PBB-TE related standard being developed by the IETF Common Control and Measurement Plane (CCAMP) working group. GMPLS should coordinate with the data plane standardization of the IEEE.  Documents on the PBB-TE control plane released by the IETF CCAMP working group include a few on the requirements, architecture, and control protocols of GMPLS controlling Ethernet.

2 MPLS-TP

2.1 Development History
The International Telecommunication Union’s Telecommunication Standardization Sector (ITU-T) SG15 started working on Transport MPLS (T-MPLS) standardization as early as 2005. Based on MPLS and transport architecture, T-MPLS simplifies MPLS by eliminating technical content that is not connection-oriented, abandoning complex protocol families, and adding OAM and protection in the style of legacy transport networks. In 2006, the ITU first approved three standard recommendations for T-MPLS architecture, interface, and equipment functions and features. Following that, the standard recommendations for OAM, protection, and network management were successively proposed. In the ITU-T SG15 Q12+Q14 interim meeting held in Stuttgart in September 2007, the IETF mission indicated that ITU-T’s T-MPLS standards conflicted with IETF’s related standards.  Reserved bytes and reserved numbers of MPLS protocols, for example, were used without any negotiation with IETF, even though IETF defined the core part of MPLS protocols.   

    At the February 2008 ITU-T SG15 plenary meeting held in Geneva, Groups Q12 and Q14 reported the debate on T-MPLS protocols. The meeting resulted in a Joint Working Team (JWT) being established to evaluate options for evolving MPLS technology to meet requirements of the transport network. The JWT comprised the T-MPLS Ad Hoc group of ITU-T and MPLS Interoperability Design (MEAD) team. The JWT chairmen were Malcolm Betts, the Q12 rapporteur, and David Ward from IETF. After a series of teleconferences, in April 2008, the JWT decided that ITU-T and IETF would cooperate to develop related standards. ITU-T would provide transport requirements to IETF; and to meet these requirements, would expand MPLS OAM, network management, and control plane protocols through the IETF’s standard procedure. The technology was renamed MPLS-TP. IETF’s MEAD team was responsible for defining MPLS-TP. In July 2008, the IETF 72nd meeting released MPLS-TP related individual drafts on requirements, framework, MPLS generic associated channel, network management, OAM analysis and requirements, and survivability framework.

 
    WP3 openly discussed T-MPLS/MPLS-TP documents at the February 2008 ITU-T SG15 plenary meeting. The WP3 chairman used pages 7-10 of the powerpoint document provided by the JWT to eliminate bias and make clear the following: MPLS-TP standards would be jointly developed by IETF and ITU-T, as shown in Figure 1; ITU-T would stop work on T-MPLS standards; the released T-MPLS standards would remain unchanged; ITU-T would not make any standard revision or engage in new standard development until IETF’s related standards became stable; and the technology name would be changed to MPLS-TP.

    Drafts on MPLS-TP framework, network management, MPLS generic associated channel, and OAM that were submitted to the IETF 74th meeting in March 2009 became the working group documents.
ITU-T SG15 Q9, Q10, Q12, and Q14 held a joint meeting to discuss revision of MPLS-TP standards in May 2009. At the meeting, editors provided the revised versions of G.8110.1, G.8110.1 amd1, G.8112, G.8121, G.8131, G.8151, G.8101, the G.8132 draft, and the G.mpls-tpoam draft. At the meeting it was agreed that standards would be approved in the sequence G.8110.1, G.8101, G.7712, G.8112, G.8121, G.8131 and G.8151.

2.2 Progress of Standard Development

2.2.1 ITU-T
The second ITU SG15 meeting in the 2008-2012 study period was held in Geneva between September 28 and October 9, 2009. The joint meeting of MPLS-TP Q9, Q10, Q12, and Q14 discussed IETF mail correspondence, and also created new correspondence.

    (1)TD218-WP3 "LS: Restructure of MPLS-TP Work Forums in the IETF." 
    IETF notified ITU-T that it would dismiss the IETF MEAD team with the purpose of conducting MPLS-TP standardization work according to the normal IETF standardization procedure. It would enable all IETF members to participate in MPLS-TP standardization work earlier. MPLS-TP related tasks would be undertaken by five related IETF working groups. Discussions on MPLS-TP might be conducted through the IETF MPLS-TP mailing list. Adrian Farrel, the chairman of the routing area and representative of IETF, would be responsible for the general coordination of MPLS-TP work, while the chairmen of the five working groups would execute detailed working plans. A committee would be established to coordinate with ITU, with members including the study subject chairmen, WP3 chairman, the SG15 chairman of ITU-T, as well as the working group chairmen and routing area chairman of IETF. The committee members would convene regularly to exchange information and promote MPLS-TP standardization. Information arising from this committee would be provided to ITU-T participants through the mailing list. The original JWT and Ad Hoc was to remain unchanged, but the Ad Hoc website would be updated to reflect current work.

    (2)TD167-WP3 "LS - New version of the MPLS-TP process document available" 
    This document aimed to explain the normal IETF working procedure and interactions with ITU-T. It is helpful for the ITU-T members to understand the IETF procedure and to participate in IETF work according to the procedure. This document is currently a working group draft, and will be further promoted. It is expected to be released as a history RFC. The draft should be updated according to TD218-WP3, and ITU-T has provided some comments and sent correspondence
to IETF.

    (3)TD200-WP3 "LS: Progress report on MPLS-TP documents" 
    This provides a list of MPLS-TP related Requests for Comments (RFC) and standards being developed. It also shows the steps involved in RFC development. The working group’s last call is critical in the RFC release procedure. The last call of a RFC usually requires two weeks, and may be repeated once. In total, the last calls of 20 standards require about 80 weeks. Renewing the last call should be avoided in order to save time. Therefore, ITU-T experts are expected to submit informal comments in the early stage of opening an MPLS-TP document, and this can avoid or significantly decrease comments from ITU-T in the formal review period of a last call.

    Figure 2 shows reference relations among ITU-T standards.

    Figure 2 does not show G.8101 because the development of G.8101 depends on the completion of all the other standards, including the terminologies. Dotted lines in Figure 2 indicate the initial version of G.8151, which may not include the linear and ring protection models.
The MPLS-TP standards to be submitted for approval are divided into three stages: G.8110.1, G.7712, G.8112; G.mpls-tp oam, G.8121, G.8151; and G.8131, G.8132, G.8152.

    If a referenced RFC is approved, the corresponding ITU-T standard may also be approved, and IETF should check the corresponding ITU-T standard at the same stage. The original versions of these standards have existed, and they must be in line with developed RFCs. The current plan involves approving the first-stage ITU-T standards at the next SG15 plenary session, and these standards will be discussed through mail and interim meetings before the session.

2.2.2 IETF
At the IETF 76th meeting held in Hiroshima between November 8 and 13, 2009, the MPLS-TP drafts were discussed by the MPLS working group. Since there were many MPLS-TP related personal documents submitted for the meeting, the MPLS working group arranged two MPLS meeting segments and one meeting segment of the Pseudo Wire Emulation Edge-to-Edge (PWE3) working group to discuss them.

    Table 1 lists MPLS-TP related IETF RFCs and working group documents, and Table 2 lists the individual documents submitted for the IETF 76th meeting.

3 Conclusion
The emergence of IP services results in IP based networks. Legacy networks using Time Division Multiplexing (TDM) switching are gradually shrinking and being replaced by packet networks. Packet transport networking is an inevitable outcome of IP based networks. The progress of its standardization will significantly impact the development of the entire industrial chain.

Refernces
[1] IEEE 802.1Qay. IEEE standards for local and metropolitan area networks: virtual bridged local area networks, amendment 7: provider backbone bridge traffic engineering [S]. 2009.
[2] Report of working party 3/15, transport network structures [R]. T09-SG15-081201-TD-WP3-0080 MSW-E (Geneva meeting). 2008.
[3] Report of working party 3/15, transport network structures [R]. T09-SG15-090928-TD-WP3-0212 MSW-E (Geneva meeting). 2009.
[4] IETF RFC 5654.MPLS-TP requirements [S]. 2009.

[Abstract] Global operators are in the process of constructing next generation IP packet-switched networks, with the view of moving towards full IP-based networks. As data services increase, improvements in bandwidth, Quality of Service (QoS), Operation Administration and Maintenance (OAM), and network reliability are required. Convergence of network data transmission and network communications technology has been driven by converged IP services (including video, voice, and data), and unified multi-service load demand. Packet Transport Networking (PTN) has come into being to meet these requirements, and PTN Standards are being developing rapidly.