MPLS Working Group X. Dai Internet-Draft B. Wu Intended status: Standards Track J. Yang Expires: April 19, 2010 ZTE Corporation October 16, 2009 MPLS-TP Lock Instruction draft-dai-mpls-tp-lock-instruct-00 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 April 19, 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. Dai, et al. Expires April 19, 2010 [Page 1] Internet-Draft MPLS-TP Lock Instruction October 2009 Abstract The aim of this document is to define an MPLS-TP OAM mechanism to meet the requirements for Lock Instruction functionality as required in MPLS-TP OAM Requirements document[MPLS-TP OAM Requirements]. The protocol solutions developed to performe this function apply to P2P bidirectional paths, P2P unidirectional paths and P2MP paths. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Definitions and terminology . . . . . . . . . . . . . . . 4 3. MPLS-TP Lock Instruction Message . . . . . . . . . . . . . . . 5 3.1. MPLS-TP Lock Instruction message Indentification . . . . . 5 3.1.1. In-band message Indentification . . . . . . . . . . . 5 3.1.2. Out-of-band message Indentification . . . . . . . . . 5 3.2. MPLS-TP Lock Instruction Message Format . . . . . . . . . 5 3.3. Optional TLVS . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Source and Destination MEP TLV . . . . . . . . . . . . 8 3.3.2. Authentication TLV . . . . . . . . . . . . . . . . . . 8 4. MPLS-TP Lock Instruction Operations . . . . . . . . . . . . . 9 4.1. General Procedures . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Sending a lock request message . . . . . . . . . . . . 9 4.1.2. Receiving a lock request message . . . . . . . . . . . 9 4.1.3. Sending a lock response message . . . . . . . . . . . 9 4.1.4. Receiving a lock response message . . . . . . . . . . 9 4.1.5. Unlock procedures . . . . . . . . . . . . . . . . . . 10 4.2. Example Topology . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative references . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Dai, et al. Expires April 19, 2010 [Page 2] Internet-Draft MPLS-TP Lock Instruction October 2009 1. Introduction MPLS-TP OAM Requirements document[MPLS-TP OAM Requirements] lists architectural and functional requirements for the Operations, Administration and Maintenance of MPLS Transport Profile. One of these functionalities is Lock Instruction, which can enable an End Point of a PW, LSP or Section to instruct its associated End Point(s) to lock the PW, LSP or Section. Further, this function SHOULD be performed on-demand between End Points of PWs, LSPs and Sections. Besides, MPLS-TP OAM Requirements document also requires that the protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional[RFC5654] LSPs, point-to-point unidirectional LSPs and point-to-multipoint LSPs. The solutions proposed in this draft can meet all the above requirements. When an operator wants to set a path into loopback mode for management purposes, e.g., to test or verify connectivity to a specific node on the path, to test the performance with respect to delay/jitter/throughput, etc., especially out-of-service performance measurement, which may affect user traffic transmition, one SHOULD first set that path to lock mode. Through this mechnism, associated nodes can distiguish this management situation from a failure situation on the tested path. Dai, et al. Expires April 19, 2010 [Page 3] Internet-Draft MPLS-TP Lock Instruction October 2009 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 RFC2119. 2.1. Abbreviations MPLS-TP: Transport Profile for Multi-protocal Label Switching OAM: Operations, Administration and Maintenance MEP: Maintenance End Point MIP: Maintenance Intermediate Point P2MP: Point to multi-point P2P: point to point TLV: Type-Length-Value 2.2. Definitions and terminology unidirectional lock: A lock operation that only locks one direction of a bidirectional path. bidirectional lock: A lock operation that locks both directions of a bidirectional path. Dai, et al. Expires April 19, 2010 [Page 4] Internet-Draft MPLS-TP Lock Instruction October 2009 3. MPLS-TP Lock Instruction Message This section proposes one message format for lock instruction operation, and two optional TLVs. 3.1. MPLS-TP Lock Instruction message Indentification 3.1.1. In-band message Indentification In the in-band option, under MPLS label stack of the MPLS-TP LSP, the ACH[RFC5586] with "MPLS-TP Lock Instruct" code point indicates that the message is an MPLS-TP Lock Instruction message, the ACH format in this case is shown as 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved |0xHH(MPLS-TP Lock Instruct) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: In-band message Indentification The first nibble (0001) indicates the ACH. The version and the reserved values are both set to 0. MPLS-TP lock instruction code point is 0xHH. [HH to be assigned by IANA from the PW Associated Channel Type registry.] 3.1.2. Out-of-band message Indentification [To be added in future] 3.2. MPLS-TP Lock Instruction Message Format The proposed format of an MPLS-TP Lock Instruction Message is shown in Figure 2. Dai, et al. Expires April 19, 2010 [Page 5] Internet-Draft MPLS-TP Lock Instruction October 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Lock Type | Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return Code | Cause Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV's | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MPLS Lock Instruction Message Format Version The Version Number is currently 0. (Note: the version number is to be incremented whenever a change is made that affects the ability of an implementation to correctly parse or process an MPLS-TP Lock Instruction message. These changes include any syntactic or semantic changes made to any of the fixed fields, or to any Type-Length-Value (TLV) or sub-TLV assignment or format that is defined at a certain version number. The version number may not need to be changed if an optional TLV or sub-TLV is added.) Message Type Two message types are defined as shown below: Message Type Description ------------ -------------- 0x0 lock request 0x1 lock response 0x2 unlock request 0x3 unlock response Lock Type Three lock types are defined as shown below: Lock Type Description --------- ------------------ 0x0 unidirectional lock 0x1 bidirectional lock Dai, et al. Expires April 19, 2010 [Page 6] Internet-Draft MPLS-TP Lock Instruction October 2009 0x2 lock clear Period This feild (in seconds) is an indication of transmition interval for MPLS-TP Lock instruction message. Return Code Value Meanings ------ ---------- 0 Failure 1 Success Cause Code Value Meaning ----- ----------------------- 0 No cause code 1 Fail to match destination MEP ID 2 Malformed lock request received 3 One or more of the TLVs is/are unknown 4 Authentication failed 5 MPLS-TP Path already locked 6 MPLS-TP Path already unlocked 7 Fail to lock MPLS-TP Path 8 Fail to unlock MPLS-TP Path The Return code and Cause code only have meaning in a Lock response message. In a Lock request message, the return code and cause code must be set to zero and ignored on receipt. 3.3. Optional TLVS This section defines two TLV types that will be used in an MPLS-TP lock instruction message, both these two TLVs are optional. Dai, et al. Expires April 19, 2010 [Page 7] Internet-Draft MPLS-TP Lock Instruction October 2009 3.3.1. Source and Destination MEP TLV This TLV is used to identify the source or destination node(s) of the path that will be locked by an operator. In a Lock message, it MUST only has one source MEP TLV; but for destination MEP TLV, it has one in a P2P path while more than one in a P2MP path. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | Length = 0xx | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Source and Destination MEP TLV 3.3.2. Authentication TLV A variable length key can be carried in an optional authentication TLV which can be included in the MPLS Lock request message. The use of authentication key is outside the scope of this document. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | Length = 0xy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Authentication TLV Dai, et al. Expires April 19, 2010 [Page 8] Internet-Draft MPLS-TP Lock Instruction October 2009 4. MPLS-TP Lock Instruction Operations 4.1. General Procedures 4.1.1. Sending a lock request message When an operator wants to lock an LSP, it first creates lock request messages according to lock type: unidirectional lock or bidirectional lock. Then it sends lock request messages periodically to destination node(s) according to the interval specified by period feild. This message may carries source/destination MEP TLV, or authentication TLV. 4.1.2. Receiving a lock request message When a node receives a lock request message, it first examines whether the source or destination MEP match with itself. If source MEP does not match, the event is logged and processing ceases. In case of bidirectional lock, if the destination MEP does not match, it will send a response message with a return code of 0 and a cause code 1. Futhermore, it will excute more examinations as specified in section 4.2. 4.1.3. Sending a lock response message Note: In case of unidirectional lock, the receipt node first identifies whether the path is a bidirectional path or a unidirectional path. If the requested path is unidirectional, it will not send lock response messages to the source node; otherwise, it will send a response message along the backward direction to the source node. After all the examinations in the former step, the receipt node of lock request message will create a response message according to the examined results, with proper return code and cause code. 4.1.4. Receiving a lock response message When the source node receive a lock response, it will parse this message, and: (1) if the return code is "success", it will cease to send lock request messages to destination node(s). (2) if the return code is "failure", it will keep on sending lock request messages to destination node(s) until it receives the first lock response message with return code "success". Dai, et al. Expires April 19, 2010 [Page 9] Internet-Draft MPLS-TP Lock Instruction October 2009 4.1.5. Unlock procedures When the source node wants to unlock a path which is in a locked state, it SHOULD do as below: (1) The source node sends an unlock request message to destination node(s), thereinto lock type is "lock clear" and message type is "unlock request". (2) When a destination node receives such a unlock request message, if it agrees to unlock this path as well as this path is a bidirectional path, it will send an unlock response message to the source node with a return code "success". If this path is a unidirectional path, it won't send a respose message. The source node will stop sending unlock request messages once it receives a response message with a return code "success". 4.2. Example Topology Assume an MPLS-TP bidirectional LSP (either associated bidirectional or co-touted bidirectional[RFC5654]) A--B--C--D, where node A and D are MEPs, B and C are MIPs[MPLS-TP Framework]. For unidirectional lock instruction, in case of lock the direction from A to D: (1) Node A periodcally sends Lock instruction messages to node D, in which lock type is unidirectional lock, and message type is lock request. (2) On receipt of such a message, node B and C transparently transmit it to next downstream node(s). (3) While node D receives the message, it will analyse it and node D knows that this is an unidirectional lock. it will create a lock response massage according to the rules below: a. if the source MEP ID does not match, the event is logged and processing ceases. b. if the destination MEP ID does not match, D sends a response with a return code of 0 and a cause code 1. Then D examines the message, and: c. if the message is malformed, it sends a response with a return code of 0 and a cause code 2 back to A. Dai, et al. Expires April 19, 2010 [Page 10] Internet-Draft MPLS-TP Lock Instruction October 2009 d. if message authentication fails, it MAY sends a response with a return code of 0 and a cause code 4 back to A. e. if any of the TLVs is not known, it sends a response with a return code of 0 and a cause code 3 back to A. It may also includes the unknown TLVs. f. if the path is already locked, it sends a response with return code of 1 (success) and a cause code 5 back to A. g. if the path is not already locked and cannot be locked, it sends a response with a return code of 0 and a cause code 7 back to A. h. if the path is successfully locked, it sends a response with an return code of 1 (success) and a cause code 0 back to A After the above operations, the direction from A to D is locked, while node D can also transmits user traffic and OAM massages to node A. For bidirectional lock instruct, which means lock both directions from A to D and D to A: (1) Node A periodcally sends Lock instruction messages to node D, in which lock type is bidirectional lock, and message type is lock request. (2) On receipt of such a message, node B and C transparently transmit it to next node(s). (3) While node D receives this message, it will analyses it. After that, node D knows that this is an bidirectional lock, it will create a lock response massage according to the rules above, and sends it to node A. Through the above operations, both directions of this bidirectional path are locked, which means node A and D can neither transmit user traffic to each other. Dai, et al. Expires April 19, 2010 [Page 11] Internet-Draft MPLS-TP Lock Instruction October 2009 5. IANA Considerations HH to be assigned by IANA from the PW Associated Channel Type registry. Dai, et al. Expires April 19, 2010 [Page 12] Internet-Draft MPLS-TP Lock Instruction October 2009 6. Security Considerations This section will be added in a future version. Dai, et al. Expires April 19, 2010 [Page 13] Internet-Draft MPLS-TP Lock Instruction October 2009 7. Acknowledgement TBD. Dai, et al. Expires April 19, 2010 [Page 14] Internet-Draft MPLS-TP Lock Instruction October 2009 8. References 8.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. 8.2. Informative References [MPLS-TP Framework] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "A Framework for MPLS in Transport Networks", September 2009. [MPLS-TP OAM Requirements] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in MPLS Transport Networks", August 2009. Dai, et al. Expires April 19, 2010 [Page 15] Internet-Draft MPLS-TP Lock Instruction October 2009 Authors' Addresses Xuehui Dai ZTE Corporation 4F,RD Building 2,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52877612 Email: dai.xuehui@zte.com.cn Bo Wu ZTE Corporation 4F,RD Building 2,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52877276 Email: wu.bo@zte.com.cn Jian Yang ZTE Corporation 5F,R&D 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 Dai, et al. Expires April 19, 2010 [Page 16]