The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) and the IETF have agreed that the next-generation transport network will be based on MPLS (multiprotocol-label-switching) technology developed within the IETF. It has been mutually agreed that the IETF and ITU will work together to extend IETF MPLS functionality to address the needs of the transport network. The work will move forward with the recognitions that the sole design authority for MPLS resides within the IETF and that expertise for Transport Network Infrastructure resides within ITU-T Study Group (SG) 15.
The need for a solution to the problem of designing a packet-based transport network solution based on IETF MPLS has led to a level of technical cooperation between the IETF and the ITU-T not previously required. As a result, a new organizational structure was developed, and a design framework that both conforms to the IETF MPLS architecture and satisfies the needs of the service pro-viders that look to the ITU-T to meet their transport network needs was designed.
History
For a number of years, the ITU-T has been designing a label-switched protocol for transport networks, which provide the wide-area connectivity on which other services – such as IP or phone networks – run. The ITU-T chose to adapt the IETF’s MPLS to this task and introduced a protocol suite known as T-MPLS.
Late in the ITU-T design and specification cycle there were a number of liaison exchanges between the ITU-T and the IETF concerning the technology. In response, the chairs of the MPLS, PWE3, BFD, and CCAMP working groups (WGs), as well as the Routing and Internet area directors, attended a number of ITU-T meetings. During the process, the IETF became increasingly concerned that incompatibility between IETF MPLS and ITU-T T-MPLS would lead to what Stewart Bryant, PWE3 co-chair, had previously described as a “train wreck on the Internet.” Those concerns led the chairs of the IESG and the IAB to take the unprecedented step of sending a liaison to the ITU-T, stating that either T-MPLS should become a fully compliant MPLS protocol, standardized under the IETF process (so-called Option 1) or it should become a completely separate protocol with a new name and a new set of code points (so-called Option 2).
Both options were discussed at an ITU-T meeting of Question 12 Study Group 15 in Stuttgart, Germany, where it was proposed that an ITU-T-IETF joint working team (JWT) be formed to evaluate the issues and make a recommendation to ITU-T management on the best way forward.
The first meeting of the JWT oc-curred during the ITU-T Geneva plenary this past February. An IETF design team and an ITU-T focus group supported the JWT.
As a result of the work of the JWT and the resulting agreement on how to move forward, the fears that a set of next-generation network transport specifications developed by ITU-T could cause interoperability problems have been allayed.
“Given the complexity of today’s networks, it is inevitable that we will, from time to time, see conflicts in approaches. This is natural. Quickly agreeing on a common way forward is imperative. And at we have done so is an indication of the great spirit of cooperation between IETF and ITU that has been built over many years of collaboration.”
Malcolm Johnson, Director, ITU Telecommunication Standardization Bureau
The JWT Recommendation
Early in the process, members of the JWT realized it was possible to design a solution to the transport network re-quirements without changes to the MPLS architecture. To prove the feasibility of a solution to the transport network requirements that fully conformed to the IETF MPLS architecture, the JWT constructed a straw man design framework. The design framework demonstrated that it is possible to adapt the IETF MPLS architecture to satisfy the needs of the transport network with only minimal changes in the IETF MPLS architecture, thereby demonstrating the considerable flexibility of the IETF design.
While the straw man can be used to provide the starting point for development of the solution, the details for the entire solution will be considered during the IETF standardization process. In addition, there will be strict adherence to the MPLS change process. Given that a viable solution to the transport network requirements has been demonstrated, the JWT reached consensus to recommend the first option: that the ITU and the IETF agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM (operation, management, and maintenance), protection, control plane protocols, and network management to meet the requirements through the IETF Standards Process. The JWT concluded that this would be the best way to (1) fulfill the mutual goal of improving the functionality of both the transport networks and the In-ternet and (2) ensure complete interoperability and architectural soundness (see http://www.itu.int/ITUT/news-log/CategoryView,category,Study%20Group%201…).
Furthermore, it was recommended that the technology should now be known as the Transport Profile for MPLS (MPLS-TP) and that future work in the IETF on this subject should focus on the definition and design of the MPLS-TP. It was also agreed that the ITU-T would focus on the integra-tion of MPLS-TP into the transport network – which would put the current T-MPLS Recommendations into alignment with MPLS-TP – and that the ITU-T would terminate work on current T-MPLS.
The JWT found no reason to investigate the option of working independently on a solution, now that the teams were working diligently to find solutions that were compatible with IETF MPLS architecture.
MPLS Transport Profile Requirements
As described earlier, in the designing of a solution to the transport network requirement, it is necessary to consider five elements:
- Forwarding
- OAM
- Protection
- Control plane
- Network management
The operators of transport networks require that label-switched paths (LSPs) and pseudowires (PWs) be configured statically via the management plane. This is to allow the equipment to be configured by using a centralized management system that connects to equipment out of band with respect to the data plane. If a control plane is used for the configuration of the LSPs/PWs, then failure and recovery of the control plane are not allowed to impact the forwarding plane, which is akin to a requirement to sup-port nonstop routing and nonstop forwarding in the IP world.
Service providers are also requesting consistent OAM capabilities for multi-layered network and interworking of the different layers and technologies, such as Layer 2, pseudowire, and label-switched path. They want to be able to offer MPLS label-switched paths and pseudowires as a part of their transport service offerings and not to use them just to provide higher-level services, such as virtual private networks. In order to do that, they must be able to seamlessly manage label-switched paths and pseudowires at different nested levels. This is known as tandem connection monitoring (TCM), and it is used, for example, when a la-bel-switched path of pseudowire crosses multiple administrations.
Currently, MPLS and pseudowires provide a generalized protection mechanism that operates in a mesh network topology and provides one-plus-one (data on active and standby path) or one-to-one (data only on active path) protection. Service providers building transport networks have in the past used a hybrid of fast convergence and fast reroute – particularly in specialist topologies, such as rings. To support transport networks, it may therefore be necessary to provide additional protection mechanisms.
Service providers also need the OAM and the data traffic to be congruent. This is provided in pseudowires through the use of a multiplexing mechanism called the associated channel header (ACH), which allows the OAM to be multiplexed transparently over the same LSP as the pseudowire. MPLS has no equivalent general-purpose OAM multiplexing mechanism. As requirements on forthcoming solutions for the MPLS TP, the IETF inserted that no modification to the MPLS forwarding architecture should be needed and that a solution should be based on existing pseudowire and LSP constructs.
In response, the JWT proposed a new method of carrying an ACH over an MPLS LSP. This small extension to the IETF MPLS architecture was the only additional mechanism that the JWT needed to postulate. It also makes it possible to have a common OAM mechanism between pseudowires and LSPs. Thus, operational complexity and overhead are dramatically reduced, and both IETF technologies are enhanced.
The OAM-data congruency is particularly challenging in the case of link aggregation groups and equal-cost mul-tipath support. However, transport network designers do not normally apply these techniques. In the short term, at least, it is suggested that the LSPs and PWs used in transport network applica-tions avoid these topology constructs.
In general, to avoid losing LSP head-end information, transport networks require that bidirectional point-to-point paths be congruent and that there be no LSP merging – in other words, no use of LDP multipoint-to-point signalling. Multicast services operate only as point-to-multipoint services and not as multipoint-to-multipoint services. The JWT was unable to reach consensus on whether penultimate hop popping needed to be excluded from the design. The straw man design framework as-sumes that PHP is not used, but this is the subject of ongoing investigation.
When protection switching (fast re-route) is in use, the OAM function is responsible for monitoring the label-switched path or pseudowire and initi-ates path recovery actions.
It was a requirement that IP forward-ing not be required to support OAM or data packets, although an out-of-band management network running IP was considered outside the scope of the fea-sibility study.
The transport network has to be capable of being used with static provisioning systems or with a control plane. On one hand, when static provisioning was used there had to be no dependency on routing or signalling, such as GMPLS or IGP, RSVP, BGP, and LDP. On the other hand, the mechanisms and capabilities used must be able to interoperate with existing MPLS and pseudowire control and forwarding planes.
With the addition of the MPLS Transport Profile, the spectrum of services that MPLS now supports is illus-trated in Figure 1 (page 19), which is taken from the JWT report.
The Straw Man Design Framework
The straw man design framework proposed by the JWT can be found at www.ietf.org/MPLS-TP_overview-22.pdf.
In creating the straw man MPLS transport profile architecture the technical feasibility study by the JWT and IETF MPLS Interoperability Design Team introduced two new constructs: the first was the definition of a new MPLS reserved label – the MPLS-TP alert label (TAL) – and the second was the definition of a Generic Associated Channel (GE-ACH).
The GE-ACH is a generalization of the ACH mechanism already defined for pseudowires to allow the mechanism and protocols that run over it to be used in both a pseudowire context and an MPLS LSP context.
The GE-ACH allows OAM packets to be directed to an intermediated node on an LSP/PWE via a suitable combination of label stacking or proper TTL setting. The use of this approach allowed the OAM channel to be introduced into MPLS without any modification to the existing MPLS forwarding design (a design invariant). There already exists an OAM alert reserved label (label 14), which was considered for use as the TAL, but the JWT believed that reusing this label would detract from the simplicity of the proposed design and that reclaiming it would be difficult in the short term due to existing deployments. The JWT therefore recommended the allocation of a new MPLS reserved label to the TAL. For various reasons, the designers speculated that this would be label 13 (Stewart’s lucky number), and the terms TAL and label now seem to be synonymous.
The Generic Associated Channel functionality supports the FCAPS functions that need to be supported by providing the encapsulation needed to carry OAM, APS, and ECC packets across the network. Thus, it is proposed that PWE3 and MPLS use the same mechanism to carry OAM traffic, but necessarily with a different method of indicating to the receiving equipment that the OAM payload is present in the packet. This mechanism (ACH) can be unified for LSPs and PWE, enabling the same functionality for both as well as ease of implementation. The GE ACH would use code points from PW ACH space but not necessarily for PW purposes. Bringing ACH functionality into LSPs begins to blur the architec-tural line between an MPLS LSP and an MPLS pseudowire. The functional differences between an MPLS LSP and an MPLS PW must, however, be retained in the architecture. There may be specific differences that are discovered in the design phase. For reasons of security and congestion, ACH functionality for LSP and pseudowires should be limited to only OAM, APS, and ECC management-channel data.
To illustrate how these new mechanisms are applied, Figure 2 below shows how LSP, multisegment pseudowire, and tandem connection monitoring OAM will be added to the MPLS architecture. Further examples can be found in the full report of the JWT.
As can be seen in Figure 1, there is consistency between the OAM for pseudowires and LSPs.
It was shown that a great deal of IETF protocol, design, and architectural reuse can be employed to solve the transport-network requirements and that no fundamental change to the IETF MPLS architecture was considered necessary.
Figure 1
Future Organization of the Work
It is proposed that the MPLS interop design team, the JWT, and the ad hoc T-MPLS groups continue to operate as described in the ITU-T document that created them (SG 15 TD515/PLEN). As stated in the document, they are expected (1) to facilitate the rapid exchange of information between the IETF and ITU-T; (2) to ensure that the work is progressing, with a consistent set of priorities to identify gaps/inconsistencies in the solutions under development; (3) to propose solutions for consideration by the appropriate WG/Question; and (4) to provide guidance when work on a topic is stalled or technical decision must be mediated. It should be noted that none of the groups have the authority to create or modify IETF RFCs or ITU-T Recommendations. Any such work must be handled through the normal processes and channels of the respective standards bodies. For the new cooperative venture to work, direct participation in the work by experts from the IETF and ITU-T is required. For example, an IETF MPLS Interoperability Design Team needs to be chartered so as to produce an MPLS-TP architectural documentation hierarchy. However, all documents would then progress in the appropriate IETF WGs according to the usual procedures.
It is assumed that ITU-T participants will be active members of the design teams and that drafts will be reviewed by the ITU-T prior to completion of WG last call. ITU-T review will be handled by correspondence, and the results of the review will be conveyed via a liaison statement. Review by cor-respondence will avoid delaying WG last call to align with an ITU-T SG/ experts meeting. Early allocation of RFC numbers and IANA code points once a document has completed IESG review are also expected to expedite the joint standards work.
The normative definition of the MPLS-TP that supports the ITU-T transport network requirements will be captured in IETF RFCs. The ITU-T will develop Recommendations for allowing MPLS-TP to be integrated with current transport equipment and networks. It will, with the agreement of the IETF, define any ITU-T specific functionality within the MPLS-TP ar-chitecture, using the (G)MPLS change process (RFC 4929), and will revise ex-isting Recommendations to align with MPLS-TP.
The normative definition of the MPLS-TP that supports the ITU-T transport network requirements will be captured in IETF RFCs. The ITU-T will:
- Develop recommendations that allow MPLS-TP to be integrated with current transport equipment and networks
- Specify any ITU-T-specific functionality within the MPLS-TP architecture – via the MPLS change process (RFC 4929)
- Revise existing Recommendations to align with MPLS-TP via the MPLS change process
ITU-T MPLS-TP Recommendations will rely on normative references to RFCs. Final text for consent will be provided to the IETF for review, and initiation of the AAP process should be timed so that members can base their AAP comments on an appropriate IETF WG consensus review of the consented text. Early communication among liai-sons and the JWT should make it possible to avoid major comments on the final documents; for example, the draft Recommendation for consent should be sent to the IETF for review prior to the SG meeting that plans to approve them.
Figure 2
Conclusion
The IETF and ITU have agreed that they will work together to extend IETF MPLS functionality to address the needs of the transport network. The work will move forward in the recognition that the sole design authority for MPLS resides within the IETF and that the domain of expertise for transport network infrastructure resides within ITU-T SG 15. The agreement to work together to design MPLS-TP resolves the issue of the ITU-T design’s being incompatible with widely deployed IETF MPLS technology.
“We do not often encounter concerns that make ITU-T designs noninteroperable with IETF designs, so we had to improvise a structure in which to effectively embed the problem solving in our processes,” said IAB chair Olaf Kolkman. “All in all, it has been somewhat of a rough ride, but the outcome is satisfactory because of hard work and a goal-oriented approach by everybody involved.”
IETF chair Russ Housley agreed, expressing optimism over the outcome. “I see this as a significant milestone in the cooperation between the ITU-T and the IETF.”
It is also, of course, a major milestone in the history of MPLS and the design of transport networks.
Loa Andersson has been active in several standards organizations for more than 15 years. He is now a co-chair of the MPLS WG and a member of the IAB.
Stewart Bryant has been active in the IETF, ITU-T SGs 13 and 15, and IEEE 1588. He is now co-chair of the PWE3 and TICTOC WGs and is IETF liaison representative to the ITU-T for MPLS issues.