MPLS Y. Ji Internet Draft Y. Lu Intended status: Standards Track Z. Du Expires: March 2010 BUPT University September 4, 2009 The Mechanism of MPLS-TP OAM Communication Based on MPLS-TP Sign Label draft-ji-mpls-tp-sign-label-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on March 4, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Ji, et al. Expires March 4, 2010 [Page 1] Internet-Draft MTSL September 2009 This document extends the applicability of the Generic Associated channel Label (GAL), enabling the realization of the communication between a Maintenance End Point (MEP) and a Maintenance Intermediate Point (MIP) in the MPLS-TP OAM architecture. This mechanism can only be used in the point-to-point co-routed bidirectional path of MPLS- TP networks. By introducing the MPLS-TP Sign Label, it enables the peer MEP to obtain the path information along the MPLS Label Switched Paths (LSPs) or MPLS pseudowires (PWs). After that, it could number the MIPs along the path, and each MIP could record the pairing relationship of the forward and the backward directions of that transport path. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Table of Contents 1. Introduction................................................2 2. MPLS-TP Sign Label..........................................3 3. Path Numbering Mechanism.....................................5 4. TTL LFIB....................................................7 5. Related ACH TLV Format.......................................8 5.1. The confirmation request message........................9 5.2. The confirmation message...............................10 5.3. The path numbering reply message.......................10 6. Applicability..............................................11 7. Security Considerations.....................................11 8. IANA Considerations........................................11 9. References.................................................12 9.1. Normative References...................................12 9.2. Informative References.................................12 10. Acknowledgments...........................................12 1. Introduction MPLS-TP OAM operates in the context of Maintenance Entities (MEs). For example, in the point-to-point co-routed bidirectional path of MPLS-TP networks, an ME includes two Maintenance End Points (MEPs), which reside at the boundaries of the ME, and MAY also include zero or a set of Maintenance Intermediate Points (MIPs), which reside within the ME, between the MEPs [8]. Ji, et al. Expires March 4, 2010 [Page 2] Internet-Draft MTSL September 2009 MEPs are capable of initiating and terminating OAM messages. Meanwhile, MIPs are unaware of any OAM flows running between MEPs or between MEPs and other MIPs. MIPs can only receive and process OAM packets addressed to the MIP itself. When an MEP need to send an OAM message to an MIP, it sets the TTL of the LSP, Tandem Connection Monitoring (TCM) or PW label so that it will expire when the target MIP is reached. Then MIPs will find that the packet has a GAL just below the current label, so it will make a further scrutiny. After proper processing, a reply, if required, is returned to the MEP that originated this message [9]. When the OAM packets are encapsulated in an IP header by default, the process above is easy to realize. But MPLS-TP OAM can not rely on this mechanism. In the environments where IP based routing and forwarding are not supported, how to send this reply and make the MEP know which MIP sends the message is uncertain. This document proposed a method to specify how the reply is returned and the related number mechanism by extending the former mechanism. The basic idea is that in the point-to-point co-routed bidirectional path of MPLS-TP networks, an MIP will record the pairing relationship of the forward and the backward directions of that transport path in a special Time To Live Label Forwarding Information Base (TTL LFIB). Therefore, when it receives an OAM packet and need to reply, the MIP will refer to the TTL LFIB to find the outgoing label and the egress interface and accomplish the reply process. The outline of the mechanism is as follows. Firstly, the source MEP sends a path numbering request packet along the path to the peer MEP, which is also received by each MIP. When the MIPs receive this packet, they will record the label information of the packet in TTL LFIB and add the swap label information about this path to the packet before forwarding. Secondly, the peer MEP receives this packet, and it will send a confirmation request message to each MIP. When the MIPs receive this message, they will accomplish the path information in the TTL LFIB and return a confirmation message. Finally, the peer MEP receives those confirmation messages. If they are all success ones, it will send a success path numbering reply message to the source MEP. 2. MPLS-TP Sign Label In order to realize the path numbering and TTL LFIB establishing, the peer MEP should obtain the path information firstly. This document specifies that a label is used for that purpose and calls Ji, et al. Expires March 4, 2010 [Page 3] Internet-Draft MTSL September 2009 this special label the MPLS-TP Sign Label (MTSL). One of the reserved label values defined in RFC 3032 [2] is assigned for this purpose. The value of the label is to be allocated by IANA; this document suggests the value 4. The use of this label is analogous to the use of the Router Alert Label. This label can be present anywhere in the label stack except at the bottom. When the MTSL is the top label, it alerts the Label Switching Router (LSR) that the packet needs a closer look. Therefore, the packet is not forwarded in hardware, but is looked at by a software process. When the packet is received, the MTSL is removed. Then a lookup of the next label in the label stack is performed in the Label Forwarding Information Base (LFIB) to decide where the packet needs to be switched to. Next, a special label action (push, swap, pop) is performed. If the label action is push, which means the LSR is a subnetwork ingress, the MTSL will be pushed back before normal push action and will become invisible until the egress of the subnetwork. If the label action is swap, which means the LSR is an MIP, the new label will be pushed into the label stack instead of a normal swap action. After that, the MTSL is pushed back on top of the label stack, and the packet is forwarded. If the label action is pop, it means that the packet gets to its destination, the peer MEP. The format of the MTSL is shown in Figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTSL | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MTSL: Label Value, 4 is supposed TC: Traffic Class S: Bottom of Stack, always zero here TTL: Time to Live, 255 is initialed Figure 1 The Format of the MTSL Figure 2 shows the packet received by the peer MEP. Ji, et al. Expires March 4, 2010 [Page 4] Internet-Draft MTSL September 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTSL | TC |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP or PW Label | TC |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP or PW Label | TC |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Other labels recorded along the path ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...... Figure 2 The Path Numbering Packet Received by the Peer MEP If the MTSL message exceeds the path MTU because of recording the path's information continuously, the path numbering will fail. The necessary logging and alarming will help the administrator to solve the problem. 3. Path Numbering Mechanism This mechanism can be used in the point-to-point co-routed bidirectional path of MPLS-TP networks. This path's forward and backward directions follow the same route (links and nodes) across the network. Both directions are setup, monitored and protected as a single entity [10]. The path may be an LSP or a PW with two Label Edge Routers (LERs) and one or more LSRs. The two LERs act as the source MEP and the peer MEP, and the LSRs act as the MIPs. After the path is established, it is supposed that the two MEPs know this path is a co-routed bidirectional path and the pairing relationship of the two labels assigned to the forward and the backward directions in this MEP. For the realization of this mechanism, the MEPs SHOULD maintain an MIP number value in this path's maintenance information, whose default value is -1. This mechanism will start just after the establishment of the path. The first step is to send the path numbering request message, whose purpose is to number the MIPs and provide the path information hop- by-hop to the peer MEP kindly like the function of the Record Route Ji, et al. Expires March 4, 2010 [Page 5] Internet-Draft MTSL September 2009 Object in RSVP-TE [3]. The source MEP sends a special packet with an MTSL at the top of the label stack along the path to the peer MEP, which is also received by each MIP. When the MIPs receive this packet and find the MTSL, it is delivered to a local software module for processing. The process procedures are as follows. Firstly, it records the TTL value of the MTSL, and then removes the MTSL. The actual forwarding of the packet is determined by the label beneath the MTSL in the stack. Secondly, it looks up the label in the LFIB. It will find the matching element because the path has been established and the action should be swap. After that, it records the result, finishing the forward numbering of the path in the TTL LFIB. Thirdly, it changes the current label's S bits to 1, and pushes the new label found in LFIB into the label stack, which has the same TC bits, S bit and TTL bits as the current label. Finally, it pushes back the MTSL and updates the TTL bits by decreasing the TTL value recorded before by 1. And then, it forwards the new packet which is a little bigger than before according to the result of the former LFIB lookup. When the peer MEP receives this packet and finds the MTSL, what it does is a little different. Its process procedures are as follows. Firstly, it records the TTL value of the MTSL, and then the MTSL is removed. This step is the same as the former. Secondly, it looks up the label in the LFIB. It will find the matching element and the action should be pop. After that, it sends a confirmation request message to each MIP along the path. This is achieved by sending messages along the backward path to the source MEP with the TTL set successively to 1, 2, and so on. The total number of the messages will be the number of the MIPs, which is computed as 255 minus the current TTL value recorded in the first step of MTSL process procedure. Thirdly, after the MIPs receive this message because of the TTL expiring, they will accomplish the path information in the TTL LFIB and return a confirmation message to the peer MEP. Finally, the peer MEP receives those confirmation messages. If they are all success ones, it will send a success path numbering reply Ji, et al. Expires March 4, 2010 [Page 6] Internet-Draft MTSL September 2009 message to the source MEP. And then, it will update the MIP number value in this path's maintenance information. 4. TTL LFIB TTL LFIB is analogous to LFIB and most of its data information is copied from the LFIB of the LSR. Here the per platform label space is used for example [4]. Its element includes followed contents: Forward ingress label, forward number, forward egress interface, forward egress label; backward ingress label, backward number, backward egress interface, backward egress label. When an MIP receives the MTSL packet, it will finish the forward numbering of the path in the TTL LFIB. That procedure includes three steps. Firstly, copy current incoming label beneath the MTSL to the forward ingress label. Secondly, copy the outgoing interface and label found in the LFIB to the backward egress interface and backward egress label. Thirdly, compute the forward number. Here it is supposed that when the source MEP sends the path numbering request message, which is also called MTSL message in this document, the TTL bits of the MTSL at the top of the label stack is 255 just like the default value set in RFC 3443 [5]. Then, when each MIP receives the MTSL, the TTL will decrease by one by sequence. The forward number will be computed as 256 minus the current TTL value recorded in the first step of the MTSL process procedure. When the MIPs receive the confirmation request message from the peer MEP, it will finish the backward numbering of the path in the TTL LFIB. That procedure also includes three steps. Firstly, copy current incoming label to the backward ingress label. Secondly, copy the outgoing interface and label found in LFIB according to the incoming label to the forward egress interface and forward egress label. Thirdly, set the backward number. When the peer MEP sends the confirmation request message, it will include a special ACH TLV which includes the label information brought by the MTSL message to the peer MEP. The backward number will be copied from the TLV information, which is further talked in section 5.1. After the path numbering process, each MIP will have a forward number and a backward number. The forward number will be 1, 2, 3 ... until the number of MIPs along the forward direction of the path. The backward number will also be 1, 2, 3 ... until the number of MIPs along the backward direction of the path. The forward number Ji, et al. Expires March 4, 2010 [Page 7] Internet-Draft MTSL September 2009 and backward number will only be available in this path. In fact, these two numbers also mean the number of MIPs from the MEP to the MIP. After the numbering, when an MIP receives an OAM packet addressed to itself, that is to say, the packet get TTL expiration at this MIP and the GAL is found just below the current label, and need to reply, it will refer to the TTL LFIB and perform the label swapping for the reply. As a result, the upper part of the OAM packet trace follows the forward/backward path and the lower part of the OAM packet trace follows the backward/forward path. The TTL value of the top label of the reply message is set to the forward number or the backward number according to the incoming label. Therefore, the message will also get TTL expiration at the target MEP, which could be distinguished from a normal OAM message sent by the peer MEP. Also, the message will include a special ACH TLV to indicate which MIP sends out the message. The paths of an LSR can be distinguished by the incoming label alone because the label merging is forbidden in the MPLS-TP networks. This is a basic requirement of the mechanism introduced in this document. When the bidirectional path is revoked, the information in the TTL LFIB also needs to be deleted just as the information in the LFIB. 5. Related ACH TLV Format This document has mentioned four kinds of messages, a path numbering request message, a confirmation request message, a confirmation message, a path numbering reply message. The path numbering request message is flagged by the MTSL and has its own special process procedure. Other three are normal OAM packets. They abide by the format defined in [6] and [7]. Their formats are shown in Figure 3. Ji, et al. Expires March 4, 2010 [Page 8] Internet-Draft MTSL September 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP or PW Label | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP or PW Label | TC |F| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 The Format of the Three OAM Messages The Channel Type field indicates the type of message carried on the associated control channel. Here a new channel type definition is needed because IP is not used as the multiplexer. In applications of this document, the three OAM messages all have a TTL value specially assigned at the top of the label stack and also a special ACH TLV to indicate the source information. Here three different ACH TLV types need to be allocated for the three messages, and also an ACH TLV type for the MIP addressing in the OAM communication after the path numbering need to be allocated. Its format is the same as the former three shown in Figure 3. These four kinds of TLV all have a TLV length value of 4. The value part is an MPLS label. The F bit stands for whether the message is a success message or not. 5.1. The confirmation request message After the peer MEP receives the MTSL message, it will send a confirmation request message to each MIP. The detailed format is described below. What the peer MEP receives is a label stack, the confirmation request messages will be filled according to that label stack which is called MTSLS. As said in Section 3, the MTSL will be removed firstly. In the first confirmation request message, the LSP or PW Label at the top will be the label addressed to the source MEP, and the TTL bits will be set to 1, and the label of the TLV will be copied from the label at the top of the label stack MTSLS. This label is used to Ji, et al. Expires March 4, 2010 [Page 9] Internet-Draft MTSL September 2009 be beneath the MTSL. However, its F bit will be set to 1, and the TTL bits will be set to the same as the top label. The TLV type is set to path numbering confirmation request. After that, the label at the top of the label stack MTSLS will be removed. The second confirmation request message will have the same top LSP or PW Label as the first one, and a TTL value 2. The label of the TLV will be copied from the new top label in the label stack MTSLS. The F bit is set to 1 and the TTL bits are set to 2, and the TLV type is set to path numbering confirmation request. Also, current top label in the label stack MTSLS will be removed. This procedure will loop for MIPs number times, which is computed before. After that, the top label of the label stack MTSLS will be the one initialed by the source MEP. 5.2. The confirmation message When the MIPs receive the confirmation request message, they will notice the TLV type in the message and finish the path numbering according to the label in the TLV of the confirmation request message. After that, it will refer to the TTL LFIB element newly built up to find the way back, and send a confirmation message. In the confirmation message, LSP or PW Label at the top will be the label found in the TTL LFIB, TTL bits will be set to backward number, and the label of the TLV will be copied from the top label. Meanwhile, its TLV type will be set to path numbering confirmation. Its F bit will be set to 1 to indicate it is a success message. 5.3. The path numbering reply message After the peer MEP receives all the confirmation messages, it will send a success path numbering reply message to the source MEP if they are all success ones. The detailed format is described below. LSP or PW Label at the top will be the label addressed to the source MEP, and the TTL value will be set to the MIP number plus one. The label of the TLV will be copied from the new top label in the label stack MTSLS, which is also the first label recorded. The F bit is set to 1 and the TTL bits are set to the same to the top label. The TLV type is set to path numbering reply. After the source MEP receives the success path numbering reply message, it will also update the MIP number value in this path's maintenance information. Ji, et al. Expires March 4, 2010 [Page 10] Internet-Draft MTSL September 2009 If the ME has no MIP, the mechanism of this document will not be necessary. This is easy to be discovered by the peer MEP when it receives the MTSL message. It will set the MIP number value in this path's maintenance information to zero and send a fail path numbering reply message. This message will have F bit set to 0 and TTL bits set to 1 in the label of ACH TLV. Also, the TTL of the top label is set to 1. After receiving the fail path numbering reply message, the source MEP will also set the MIP number value in this path's maintenance information to zero. 6. Applicability As talked before, the mechanism of this document can only be used in the point-to-point co-routed bidirectional path of MPLS-TP networks. It can be used in the environments where IP based routing and forwarding are supported or not supported. After the path numbering, the path will support OAM communications between an MEP and an MIP. Thus, to test the performance with respect to delay/jitter between an MEP and a certain MIP will not rely on the IP based demultiplexing. Also, this mechanism can be used combining with the BFD mechanism. If the BFD mechanism finds the path fail, the MEP can send a message to each MIP along the path to find the fail MIP. 7. Security Considerations Security considerations discussed in MPLS Generic Associated Channel [6] and MPLS Label Stack Encoding [2] apply to this document. Further security considerations will described in future versions. 8. IANA Considerations This document requests that IANA allocates a label value, to the MTSL, from the pool of reserved labels, and suggests this value to be 4. The Channel Type allocation and the Associated Channel TLV Registration discussed in MPLS Generic Associated Channel [6] and Definition of ACH TLV Structure [7] apply to this document. This document requests a new Channel Type and four new ACH TLV Types. The ACH TLV Types are path numbering confirmation request, path numbering confirmation, path numbering reply, and MIP addressing. Further IANA considerations will described in future versions. Ji, et al. Expires March 4, 2010 [Page 11] Internet-Draft MTSL September 2009 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [3] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [4] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [5] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003. [6] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [7] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., and D. Ward, "Definition of ACH TLV Structure", draft-bryant-mpls-tp- ach-tlv-02 (work in progress), May 2009. 9.2. Informative References [8] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in Transport Networks", draft-ietf-mpls-tp-framework-03 (work in progress), August 2009. [9] IETF - ITU-T Joint Working Team, "MPLS Architectural Considerations for a Transport Profile", April 2008, . [10] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "MPLS-TP Requirements", draft-ietf-mpls-tp- requirements-10 (work in progress), August 2009. 10. Acknowledgments The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the Ji, et al. Expires March 4, 2010 [Page 12] Internet-Draft MTSL September 2009 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS Transport Profile. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Yuefeng Ji Beijing University of Posts and Telecommunications P.O. Box 128, No.10, Xi Tu Cheng Road, Beijing 100876, China Phone: Email: jyf@bupt.edu.cn Yueming Lu Beijing University of Posts and Telecommunications Phone: Email: ymlu@bupt.edu.cn Zongpeng Du Beijing University of Posts and Telecommunications Phone: Email: duzongpeng@gmail.com Ji, et al. Expires March 4, 2010 [Page 13]