[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 draft-boutros-mpls-tp-li-lb

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/