MPLS Working Group G. Liu Internet-Draft J. Yang Intended status: Informational L. Jiang Expires: August 27, 2009 ZTE Corporation February 23, 2009 Multiprotocol Label Switching Transport Profile Backward Notify Message Packet draft-liu-mpls-tp-bnm-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. 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 August 27, 2009. 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Liu, et al. Expires August 27, 2009 [Page 1] Internet-Draft MPLS-TP BNM packet February 2009 Abstract This document specifies an extension to MPLS BDI packet to form a new type of OAM packet BNM(Backward Notify Message) , this BNM packet will not only have the function of informing source MEP about existing fault in the back of path like MPLS BDI packet, but also it may response or feedback to performance and test aspect. And these response or fault indication information will be encapsulated in BNM packet by the way of TLV packet. So it may decrease the number of OAM type and keep compatibility with MPLS network. on the other hand, this encapsulating these feedback or response information by the way of TLV packet will be easy to extend OAM function to operate an MPLS Transport profile(MPLS-TP) label switched path (LSP). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. MPLS-TP BNM Message . . . . . . . . . . . . . . . . . . . . . 4 3.1. Packet Loss Response TLV . . . . . . . . . . . . . . . . . 5 3.2. one-way delay reponse TLV . . . . . . . . . . . . . . . . 6 3.3. Experimental response TLV . . . . . . . . . . . . . . . . 6 3.4. Vendor Specific response TLV . . . . . . . . . . . . . . . 7 3.5. Client Signal Fail(CSF) TLV . . . . . . . . . . . . . . . 8 3.6. Fault Message Notify TLV . . . . . . . . . . . . . . . . . 8 3.7. other . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Liu, et al. Expires August 27, 2009 [Page 2] Internet-Draft MPLS-TP BNM packet February 2009 1. Introduction this document mainly introduce a kind of new OAM packet(BNM) that can extend BDI packet and use encapsulation in the way of G-ACH. It used for a MEP to inform or tell another MEP about fault and performance,i.e ,VSR,EXR etc.These response information packet may be feedbacked or informed by BNM packet , so another MEP will set out switching of LSP or path and measure link performance. for all kinds of response or notifying information, which may be encapsulated into BNM packet by the way of TLV will be sent to another MEP along MPLS-TP LSP. so it may ensure not to add the number of MPLS OAM and it is easy to extend MPLS OAM function. 2. Conventions used in this document 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. The following terminologies were defined in [Y.17TOM or Y.1711]. OAM: Operations Administration and Maintain LSP: MPLS-TP Label Switched Path. BDI:Backward Defect Indicator CSF:Client Signal Fail DMR:Delay Measurement Response DM:Delay Measurement DMM:Delay Measurement Message DMR:Delay Measurement Response EXM:Exercise Message EXR:Exercise Response LM:Loss Measurement LMM:Loss Measurement Message LMR:Loss Measurement Response Liu, et al. Expires August 27, 2009 [Page 3] Internet-Draft MPLS-TP BNM packet February 2009 MPLS:Multi-Protocol Label Switching MPLS-TP:Multi-Protocol Label Switching Transport Profile SSM:Synchronisation Status Message TLV:Type Length Value VSM:Vendor Specific Message(special message packet) VSR:Vendor Specific Response TTSI:Trail Termination Source Identifier_source LER ID+LSP ID BNM:Backward Notify Message MEP:MEG End Point 3. MPLS-TP BNM Message For mpls-tp BNM packet, it must be encapsulated by G-ACH to keep the same as all other MPLS-TP OAM packet. The G-ACH with MPLS-TP BNM code point indicates that the message is an MPLS BDI message. In addition, a 32-bit field is added to carry the message ID and the message length as shown below Figure 1: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|A|0 0 0 0 0 0 0 | Channel Type(BNM or BDI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | Figure 1 First Nibble: set 0001b; Version: the second nibble, indicates the version of the MPLS-TP OAM Message Header , here set 0000; A:the ninth bit,setting 1 indicates it is encapsulated by the way of Liu, et al. Expires August 27, 2009 [Page 4] Internet-Draft MPLS-TP BNM packet February 2009 TLV in the Message Pakcet; setting 0 indicates it is not encapsulated by the way of TLV in the Message Packet; Resv field:senven bits followed A bit will all be set 0; channel type:16bit, the field value is 0x03 that is the same as mpls BDI code point; Message ID:the 32-bits field is set by the sender. The receiver MUST include the Message ID in the response. This way, the sender can correlate a reply with the corresponding request. Message Length:the value of this field is the total length of the message in bytes excluding the length of the MPLS-TP OAM message header. 3.1. Packet Loss Response TLV Packet loss response TLV is used to reply and notify source MEP about packet loss performance of this path or LSP connection and it is the feedback or response to LMM packet. when source MEP receives the packet loss response TLV that was sent by another end MEP, it will process and analyse this TLV message packet till the MEP point can_t identify this TLV . then it will select a better LSP and switch LSP or Path. The packet loss response TLV packet show below figure 2: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length = 0 | value of packet loss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 type: the field indicates Packet Loss Response TLV; length:the length of this Packet Loss Response TLV; value: the data about packet loss for this LSP; Liu, et al. Expires August 27, 2009 [Page 5] Internet-Draft MPLS-TP BNM packet February 2009 3.2. one-way delay reponse TLV One-way delay response TLV is a response or feedback to 1DM packet that is used to request delay measure of one way by source MEP. Firstly, the source MEP of unidirectional LSP will send DMM message include time stamp of sending to another sink MEP . when sink MEP received 1DM packet and saved the time of received the 1DM packet. then computed the difference between the two time. And the difference value will be delay of this one-way LSP. Then this sink MEP will send one-way delay response TLV encapsulated in BNM message to source MEP by the return path to inform or tell source MEP about the performance value of one-way delay of this LSP. And one-way delay response TLV shows below figure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length = 0 | value of one-way delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 type: the field indicates One-way Delay Response TLV; length:the length of this One-way Delay Response TLV; value: the data about one-way delay; 3.3. Experimental response TLV Experimental response TLV is a response or feedback to EXM packet that is used for experimental activities in cases where an OAM PDU type is not defined in MPLS-TP aspect. and it can be used within an administrative domain on a temporary basis. Firstly a MEP sends a EXM packet to another MEP for experimental activities. When another target MEP receives the EXM packet and processes the packet. and then the result of experimental activity will be encapsulated into Experimental response TLV packet like EXR packet in BNM packet, then the sink MEP sends this BNM including Experimental response TLV to source MEP, so the source MEP understands or knows the result of experimental activity. The Experimental response TLV packet show below figure 4: Liu, et al. Expires August 27, 2009 [Page 6] Internet-Draft MPLS-TP BNM packet February 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length = 0 |value of experimental activity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 type: the field indicates Experimental response TLV; length:the length of this Experimental response TLV; value: the data about Experimental activities; 3.4. Vendor Specific response TLV Vendor Specific response TLV that may have the function of VSR packet is response or feedback to VSM packet that may be used to check or test Interoperability by a vendor across its equipment. Firstly Vendor Specific Equipment MEP may send VSM packet to another Vendor Specific Equipment MEP. When another MEP received the VSM packet and processed it .and then sink MEP can send a BNM packet including Vendor Specific response TLV to source MEP. And these Vendor Specific Equipment can communicate with each other . the Vendor Specific response TLV packet show below figure 5: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length = 0 | value of interoperability state +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 type: the field indicates Experimental response TLV; length:the length of this Experimental response TLV; value: the data of interoperability state; Liu, et al. Expires August 27, 2009 [Page 7] Internet-Draft MPLS-TP BNM packet February 2009 3.5. Client Signal Fail(CSF) TLV Client Signal Fail(CSF) TLV is used to to propagate a Client Signal Fail (CSF) indication to the far-end MPLS-TP client-specific sink- adaptation process on detection of a failure of the ingress client signal in case the client-layer itself does not support an alarm suppression mechanism. This BNM packet in which may have encapsulated CSF TLV can be issued by a MEP upon receiving signal fail information from its client-layer. When far-end MEP received this BNM packet including CSF TLV and processed it , the MEP detects a client-layer signal fail condition and forward this as a signal fail indication to its client-laye, this CSF TLV packet show below figure 6: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length = 0 | value of CSF state | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 type: the field indicates Client Signal Fail(CSF) TLV; length:the length of this Client Signal Fail(CSF) TLV; value: the data of CSF state; 3.6. Fault Message Notify TLV Fault Message Notify TLV that is like BDI packet is used to inform the upstream LSR that there is a defect at the downstream LSP_s LSR point. When there is a fault happened in the LSP, the downstream LSP_s LSR point can detect this fault and send FDI packet to the termination sink point. Then fault type and location information will be filled in Fault Message Notify TLV packet and further can be encapsulated into BNM packet that will be sent to the upstream LSR and trigger 1:1 or 1:n protection switching; the Fault Message Notify TLV structure show below figure 7: Liu, et al. Expires August 27, 2009 [Page 8] Internet-Draft MPLS-TP BNM packet February 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length = 0 | fault type and location | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 type: the field indicates Fault Message Notify TLV; length:the length of this Fault Message Notify TLV; value: indicates fault type and location; 3.7. other The BNM packet can not only inform or response to these information, but also it may notify or response to other information, i.e Synchronisation Status Message(SSM) may be encapsulated into a TLV packet that can be further encapsulated into the BNM packet. so by extending TLV packet, it is easy that BNM packet may support more other functions. 4. Security Considerations The security considerations for the authentication TLV need further study. 5. IANA Considerations TBD. 6. Acknowledgments TBD. 7. References 7.1. Normative References [IETF RFC4377] IETF, "IETF RFC4377(Operations and Management (OAM) Liu, et al. Expires August 27, 2009 [Page 9] Internet-Draft MPLS-TP BNM packet February 2009 Requirements for Multi-Protocol Label Switched (MPLS) Networks)", February 2006. [ITUT-Y.1711] ITU-T, "ITU-T Recommendation Y.1711(Operation Maintenance mechanism for MPLS networks)", February 2004. 7.2. Informative References [ITUT-Y.17TOM Draft] ITU-T, "Draft ITU-T Recommendation Y.17TOM (Operation Maintenance mechanism for T-MPLS layer networks)", April 2007. [MPLS-TP JWT REPORT] S.Bryant, L.Andersson, "JWT Report on MPLS Architectural Considerations for a Transport Profile", July 2008. [MPLS-TP Requirements] B.Niven-Jenkins, D.Brungard, M.Betts,N. Sprecher ,S.Ueno, "MPLS transport profile Requirements", January 2009. [Requirements for OAM in MPLS Transport Networks] M.Vigoureux, D.Ward, M.Betts , "Requirements for OAM in MPLS Transport Networks", November 2008. 7.3. URL References [MPLS-TP-22] IETF - ITU-T Joint Working Team, "", 2008, . Authors' Addresses Guoman Liu ZTE Corporation No.68, Zijinghua Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 52871606 Email: liu.guoman@zte.com.cn Liu, et al. Expires August 27, 2009 [Page 10] Internet-Draft MPLS-TP BNM packet February 2009 Jian Yang ZTE Corporation 5F,RD Building 3,ZTE Industrial Park,XiLi LiuXian Road Nanshan District,Shenzhen 518055 P.R.China Phone: +86 755 26773731 Email: yang_jian@zte.com.cn Lili Jiang ZTE Corporation No.68, Zijinghua Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 52871745 Email: jiang.lili@zte.com.cn Liu, et al. Expires August 27, 2009 [Page 11]