Network Working Group                                 Sami Boutros (Ed.)
Internet Draft                                      Siva Sivabalan (Ed.)
Intended status: Standards Track                     Cisco Systems, Inc.
Updates: 6371 (if approved)
Expires: March 29, April 3, 2012                              Rahul Aggarwal (Ed.)
                                                            Arktan, Inc.

                                                  Martin Vigoureux (Ed.)
                                                          Alcatel-Lucent

                                                        Xuehui Dai (Ed.)
                                                         ZTE Corporation

                                                     September 29,

                                                         October 3, 2011

        MPLS Transport Profile lock Instruct and Loopback Functions
                      draft-ietf-mpls-tp-li-lb-06.txt
                      draft-ietf-mpls-tp-li-lb-07.txt

Abstract

   Two useful Operations, Administration, and Maintenance (OAM)
   functions in a transport network are "lock" and "loopback". The lock
   function enables an operator to lock a transport path such that it
   does not carry client traffic, but can continue to carry OAM messages
   and may carry test traffic. The loopback function allows an operator
   to set a specific node on the transport path into loopback mode such
   that it returns all received data.

   This document specifies the lock function for MPLS networks and
   describes how the loopback function operates in MPLS networks.

   This document updates RFC 6371 section 7.1.1.

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

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This Internet-Draft will expire 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 March 29, 2012.

Abstract
   This the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document specifies one function must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and describes are provided without warranty as
   described in the Simplified BSD License.

1. Introduction

   Two useful Operations, Administration, and Maintenance (OAM)
   functions in a second function
   which transport network are applicable to "lock" and "loopback". This
   document discusses these functions in the context of MPLS transport networks.

   - The first lock function enables an operator to lock a transport path while the second enables such
     that it does not carry client traffic. As per RFC 5860 [1], lock is
     an operator to set, administrative state in loopback, a given node along a which it is expected that no client
     traffic may be carried. However, test traffic and OAM messages can
     still be mapped onto the locked transport path.
   This document also defines the extension to MPLS operation,
   administration, and maintenance (OAM) to perform the lock function.
   This document updates RFC 6371 section 7.1.1.

Table of Contents

   1. Introduction...................................................2
      1.1. Updates RFC 6371..........................................5
   2. Terminology....................................................5
   3. Lock Message...................................................5
      3.1. Message Identification....................................5
      3.2. LI Message Format.........................................6
   4. Lock, Loopback and maintenance operations......................6
   5. Operation......................................................7
      5.1. Lock Operation............................................7
      5.2. UnLock Operation..........................................7
      5.3. General Procedures........................................7
      5.4. Example Topology..........................................8
      5.5. Locking a transport path..................................8
      5.6. UnLocking a transport path................................8
   6. Security Considerations........................................8
   7. IANA Considerations............................................9
      7.1. Pseudowire Associated Channel Type........................9
   8. Acknowledgements...............................................9
   9. References.....................................................9
      9.1. Normative References......................................9
      9.2. Informative References...................................10
   Author's Addresses...............................................10
   Full Copyright Statement.........................................12
   Intellectual Property Statement..................................12

1. Introduction

   This document specifies one function and describes another function
   which are applicable to MPLS transport networks. The first function enables an operator to lock a transport path. The
   second function enables an operator to set that transport path in
   loopback at a specified node along the path. This document also
   specifies the extensions to the MPLS operation, administration and
   maintenance (OAM)
     may be applied to perform the lock function.

   The Lock function pertains to Label Switched Paths (LSPs), Pseudowires (PWs)
     (including multi-segment Pseudowires) (MS-PWs), and Sections. As
   per MPLS Sections
     as defined in RFC 5860 [1], lock is 5960 [9]).

   - The loopback function allows an administrative state in which it is
   expected operator to set a specific node on
     a transport path into loopback mode such that no client traffic may it returns all
     received data. Loopback can be carried. However, test traffic
   and OAM messages applied at a Maintenance Entity
     Group End Point (MEP) or a Maintenance Entity Group Intermediate
     Point (MIP) on a co-routed bidirectional LSP, PW or MPLS
     Section. It can also be mapped applied at a MEP on the locked transport path.

   Taking the example of an associated
     bidirectional LSP, lock is initiated by an operator.
   Typically when an LSP PW or MPLS Section.

     Loopback is locked, both ends used to test the integrity of the LSP are
   independently locked by transport path to and
     from the operator. node that is performing loopback. It requires that the
     transport is often difficult to
   coordinate these lock operations within locked and that a tight window. This document
   defines a new OAM message, Lock Instruct (LI) in order to provide the
   desired timely coordination.

   When an endpoint of an LSP or PW is locked by an operator, the MEP
   sends LI messages to its peer MEP. An endpoint considers on the LSP to
   be locked when either it receives an external operator command or
   when transport path sends test
     data which it receives an LI message.

   The Lock function can be performed using an extension to also validates on receipt.

   This document specifies the lock function for MPLS OAM
   as described in networks and
   describes how the next sections. loopback function operates in MPLS networks.

   This document updates RFC 6371 section 7.1.1 [6].

1.1. Updates RFC 6371

   This document updates section 7.1.1 of RFC 6371 [6].

   That framework makes the assumption that the Lock Instruct message is a common mechanism
   used to lock
   PWs, LSPs independently enable locking and Sections.

   The Lock function can as well be realized using requires a management plane. response message.

   The Loopback function mechanism defined in this document requires that a lock
   instruction is operated sent by management from MEP to MEP on
   bidirectional (associated and co-routed) Label Switched Paths (LSPs),
   Pseudowires (including multi-segment Pseudowires) and Sections.

   The Loopback function is additionally operated from MEP to MIP on
   co-routed bidirectional LSPs, on multi-segment Pseudowires both ends of the locked
   transport path and
   Sections.

   Loopback is a function that enables a receiving MEP to return
   traffic to the sending MEP when in the loopback state. This state
   corresponds to the situation where, at a given node, Lock Instruct message does not require a forwarding
   plane loop is configured
   response.

2. Terminology and the incoming direction of a transport
   path is cross-connected to the outgoing reverse direction. Therefore,
   except Conventions

2.1. Conventions Used in the case of early TTL expiry, traffic sent by the source
   will 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 received by that source.

   Note that before setting a given node interpreted as described in Loopback for RFC-2119 [2].

2.2. Acronyms and Terms

   ACH: Associated Channel Header

   MEG: Maintenance Entity Group

   MEP: Maintenance Entity Group End Point

   MIP: Maintenance Entity Group Intermediate Point

   MPLS-TP: MPLS Transport Profile

   MPLS-TP LSP: Bidirectional Label Switch Path

   TLV: Type Length Value

   TTL: Time To Live

   LI: Lock Instruct

   Transport path: MPLS-TP LSP or MPLS PW

3. Lock Function

   Lock is used to request a MEP to take a specific
   transport path, this transport path MUST out of service
   for administrative reasons. For example, Lock can be locked.

   Data plane loopback used to allow
   some form of maintenance to be done for a transport path. Lock is an out-of-service function, as required in
   section 2.2.5
   also a prerequisite of RFC 5860 [1]. This the Loopback function loops back all traffic
   (including user data and OAM). described in Section 4.

   The traffic can be originated from one
   internal point at the ingress of NMS or a management process initiates a Lock by sending a Lock
   command to a MEP. The MEP takes the transport path within an interface
   or inserted from input port out of an interface using an external test
   equipment. The service,
   that is, it stops injecting or forwarding traffic is looped back unmodified (other than normal
   per hop processing such as TTL decrement) in onto the direction transport
   path.

   To properly lock a transport path (for example, to ensure that a
   loopback test can be performed), both directions of the
   point of origin by an interface at either an intermediate node or a
   terminating node.

   It should transport
   path must be noted that data plane loopback function itself is
   applied to data plane loopback points residing on different
   interfaces from MIPs/MEPs. All traffic (including both payload and
   OAM) received on the looped back interface taken out of service so a Lock command is sent on to the reverse
   direction
   MEPs at both ends of the transport path.

   For data plane loopback at an intermediate point This ensures that no traffic is sent
   in a transport
   path, the loopback needs to be configured to occur at either direction. Thus, the
   ingress or egress interface.  This is done using management.

   The Loopback Lock function can be performed realized entirely
   using a the management plane. Management

   However, despatch of messages in the management plane MUST ensure that to the two MEPs are locked before performing
   may present coordination challenges. It is desirable that the
   loopback function. lock be
   achieved in a coordinated way within a tight window, and this may be
   difficult with a busy management plane. In order to provide
   additional coordination, an LI OAM message can additionally be sent.
   A MEP locks a transport path when it receives a command from a
   management process or when it receives an LI message as described in
   Section 6.

   This document defines an LI message for MPLS OAM. The Lock function LI message is
   based on a new G-ACH message using a new
   channel type ACH Type as well as an existing TLV.

   When an LSP is locked, the management or control function This is expected a common
   mechanism applicable to lock both ends. The purpose LSPs, PW, and MPLS Sections.

4. Loopback Function

   This section provides a description of the Lock instruct LI message Loopback function within
   an MPLS network. This function is to
   ensure the timely coordination of locking achieved through management
   commands and unlocking the two ends.
   Lock Instruct messages may be lost during looping or maintenance
   operations, thus locking both ends so there is required, before such
   operations occur.

   This document updates RFC 6371 section 7.1.1.

   Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", no protocol specification necessary.
   However, the Loopback function is dependent on the Lock function and "OPTIONAL" in this
   document are
   so it is appropriate to be interpreted as described describe it in RFC-2119 [2].

1.1. Updates RFC 6371

   This document updates section 7.1.1 of RFC 6371. this document.

   The mechanism
   proposed Loopback function is used to send the LI OAM message requires test the LI OAM message to be
   sent periodically and doesn't require integrity of a reply to the LI message.

2. Terminology

   ACH: Associated Channel Header

   LSR: Label Switching Router

   MEP: Maintenance Entity Group End Point

   MIP: Maintenance Entity Group Intermediate Point.

   MPLS-TP: MPLS Transport Profile

   MPLS-OAM: MPLS Operations, Administration and Maintenance

   MPLS-TP LSP: Bidirectional Label Switch Path

   NMS: Network Management System

   TLV: Type Length Value

   TTL: Time To Live

   LI: Lock Instruct

   Transport path: MPLS-TP LSP or MPLS Pseudowire.

3. Lock Message

3.1. Message Identification

   The proposed mechanism uses transport
   path from a new code point MEP up any other node in the Associated
   Channel Header (ACH) described in [4].

  The LI channel same MEG. This is identified achieved
   by setting the ACH as defined in RFC 5586 [4]
  with the Channel Type set to the LI code point = 0xHH.  [HH to be
  assigned by IANA target node into loopback mode, and transmitting a
   pattern of test data from the PW Associated Channel Type registry] MEP. The
  LI Channel does not use ACH TLVs target node loops all received
   data back toward the originator, and MUST NOT include the ACH TLV
  header. The LI ACH Channel MEP extracts the test data
   and compares it with what it sent.

   Loopback is shown below.

    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 (LI)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: ACH Indication of LI

   The LI Channel is 0xHH (to be assigned by IANA)

3.2. LI Message Format

   The format of an LI Message is shown below.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  | Reserved                              | Refresh Timer |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | a function that enables a receiving MEP Source ID TLV                      |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: MPLS LI Message Format

   Version: The Version Number is currently 1.  (Note: to return traffic
   to the version
   number is sending MEP when in the loopback state. This state corresponds
   to be incremented whenever the situation where, at a change given node, a forwarding plane loop is made that affects
   configured and the ability incoming direction of an implementation a transport path is cross-
   connected to correctly parse or process the
   message. These changes include any syntactic or semantic changes made
   to any outgoing reverse direction. Therefore, except in the
   case of early TTL expiry, traffic sent by the fixed fields, or to any Type-Length-Value (TLV) or sub-
   TLV assignment or format source will be received
   by that source.

   Data plane loopback 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.)

   Refresh Timer: The maximum time between successive LI messages
   specified out-of-service function, as required in seconds. The default value is 1. The value 0 is not
   permitted. When a lock is applied, a refresh timer is chosen.
   section 2.2.5 of RFC 5860 [1]. This
   value MUST NOT function loops back all traffic
   (including user data and OAM). The traffic can be changed for originated from one
   internal point at the duration ingress of that lock.

   MEP Source ID TLV: This is the "CC/CV MEP ID TLV" defined in [3].

4. Lock, Loopback and maintenance operations

   When a transport path within an LSP interface
   or inserted from input port of an interface using an external test
   equipment. The traffic is locked, looped back unmodified (other than normal
   per hop processing such as TTL decrement) in the management direction of the
   point of origin by an interface at either an intermediate node or control a
   terminating node.

   It should be noted that data plane loopback function itself is expected
   applied to lock data plane loopback points residing on different
   interfaces from MIPs/MEPs. All traffic (including both ends. The purpose of payload and
   OAM) received on the LI message looped back interface is to ensure sent on the
   timely coordination reverse
   direction of locking and unlocking the two ends.  LI
   messages may be lost during looping or maintenance operations, thus
   locking both ends is required, before such operations occur.

   When a transport path is put path.

   For data plane loopback at an intermediate point in loopback, traffic sent from a transport
   path, the
   sending MEP will be looped back loopback needs to that sending MEP. OAM packets not
   intercepted by TTL expiry will as well be looped back. The use of
   traffic configured to measure packet loss, delay and delay variation is outside
   the scope of this document.

5. Operation

5.1. Lock Operation

   Lock occur at either the
   ingress or egress interface.  This is used to request a MEP to take a transport path out of service
   for administrative reasons. For example, Lock done using management.

   The Loopback can be used to allow
   some form of maintenance to be done for a transport path.

   When performing Lock, in response to performed using a management request, plane. Management
   plane must ensure that the MEP
   MUST take two MEPs are locked before performing the transport path out
   loopback function.

   The nature of service test data and MUST begin sending LI
   messages periodically to the remote MEP at the remote end use of loopback traffic to measure
   packet loss, delay, and delay variation is outside the
   transport path.

   The receiver MEP once locked, MUST take scope of this
   document.

4.1. Operational Prerequisites

   Obviously, for the Loopback function to operate, there are several
   prerequisites:

   - There must be a return path, so transport path out of
   service. under test must e
     bidirectional.

   - The receiver MEP, will lock node in loopback mode must be on both the forward and return
     paths. This possible for all MEPs and MIPs on a co-routed
     bidirectional LSP, PW, or MPLS Section, but is only
     possible on for MEPs on associated bidirectional LSPs, PW,
     or MPLS Sections.

   - The transport path as long as cannot deliver client data when one of its nodes
     is in loopback mode, so it is
   receiving important that the periodic LI messages.

   A MEP transport path is
     locked either Lock was requested by management (and - as a
   result it is sending LI messages), or it is receiving LI messages
   from the remote MEP.

5.2. UnLock Operation

   Unlock before loopback is used to request a MEP to bring enabled.

   - Management plane coordination between the previously locked
   transport path back node in service.

   When a loopback mode and
     the MEP is unlocked via management or control it MUST cease sending LI messages. Further, it test data is required. The MEP must have stopped receiving LI
   messages for a period not send test
     data until loopback has been properly configured because this would
     result in the test data continuing toward the destination.

   - The TTL of 3.5 times the previously received refresh
   timer before it brings test packets must be set sufficiently large to
     account for both directions of the transport path back in service.

   A MEP would unlock transport path and put it back to service if and
   only if there is no management request to lock under test
     otherwise the path and it is packets will not
   receiving in-band LI messages.

   A MEP is unlocked when there is no management request be returned to Lock and no
   LI the originating MEP.

   - OAM messages are received.

5.3. General Procedures

   When taking a intended for delivery to nodes along the transport
     path out of service, the operation MUST under test can be
   preceded delivered by a lock operation.

5.4. Example Topology

   The next sections discuss the procedures for locking, Unlocking a
   transport path.  Assume a transport path traverses nodes A <--> B <--
   > C <--> D.  We will refer correct TTL expiry. However,
     OAM messages cannot be delivered to points beyond the Maintenance Entities involved as
   MEP-A, MIP-B, MIP-C, and MEP-D respectively. Suppose a maintenance
   operation invoked at MEP-A requires to lock loopback node
     until the transport path. loopback condition is lifted.

5. Lock Instruct Message

5.1. Message Identification

   The following sections describe MEP-A setting and unsetting a lock at
   MEP-D.

5.5. Locking a transport path

   1. MEP-A sends an in-band LI Lock Instruct Message is carried in response to a management
   request to lock the transport path. Associated Channel Header
   (ACh) described in [4]. it is identified by a new PW ACh Type of 0xHH
   (to be assigned by IANA).

5.2. LI Message Format

   The message will include the
   source MEP-ID TLV.

   2. Upon receiving the format of an LI message, D uses the received label stack and
   the source MEP-ID as per [3] to identify the transport path. If no
   label binding exists or there Message is shown below.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  | Reserved                              | Refresh Timer |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        MEP Source ID TLV                      |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: MPLS Lock Instruct Message Format

   Version: The Version Number is currently 1.  (Note: the version
   number is no associated transport path back to be incremented whenever a change is made that affects
   the originator, ability of an implementation to correctly parse or if process the source MEP-ID does not match,
   message. These changes include any syntactic or semantic changes made
   to any of the event 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
   logged added.)

   Reserved: The reserved field MUST be set to zero on transmission and processing of the
   SHOULD be ignored on receipt.

   Refresh Timer: The maximum time between successive LI message ceases.

5.6. UnLocking a transport path messages
   specified in seconds. The default value is 1. In response to The value 0 is not
   permitted. When a management request to unlock lock is applied, a refresh timer is chosen. This
   value MUST NOT be changed for the transport path
   MEP-A stops sending LI Messages.

   2. After both MEP duration of that lock. A and MEP D have not received an node
   receiving a LI message in at
   least 3.5 times the refresh timer, and each MEP has not received with a changed refresh timer MAY ignore the
   new management request value and continue to Lock apply the transport path, both MEPs SHALL
   put the transport path back in service.

6. Security Considerations

   MPLS-TP old value.

   MEP Source ID TLV: This is a subset one of MPLS the three MEP Source ID TLVs
   defined in [3] and so builds upon many of identifies the aspects of MEP that originated the security model LI message.

6. Operation of MPLS. MPLS networks make the assumption that it
   is very hard to inject traffic into Lock Function

6.1. Locking a network, and equally hard to
   cause Transport Path

   When a MEP receives a Lock command from an NMS or through some other
   management process, it MUST take the transport path out of service.
   That is, it MUST stop injecting or forwarding traffic to be directed outside onto the network. The control plane
   protocols utilize hop-by-hop security, and assume a "chain-of-trust"
   model such LSP,
   PW, or Section that end-to-end control plane security is not used. For
   more information on has been locked.

   As soon as the generic aspects of MPLS security, see [6].

   This document describes a protocol carried in transport path has been locked, the G-ACh [4], and so
   is dependent on MEP MUST send an
   LI message targeting the security MEP at the other end of the G-ACh, itself. locked transport
   path. The G-ACh is a
   generalization of source MEP MUST set the Associated Channel defined Refresh Timer value in [7]. Thus, this
   document relies heavily on the security mechanisms provided for the
   Associated Channel and described in [4] LI
   message and [7].

   A specific concern for MUST retransmit the G-ACh is that LI message at the frequency indicated
   by the value set.

   When locking a transport path, the NMS or management process is can be used
   required to provide send a
   covert channel. This problem is wider than the scope of this
   document and does not need Lock command to be addressed here, but it should be
   noted that the channel provides end-to-end connectivity and SHOULD
   NOT be policed by transit nodes. Thus, there is no simple way both ends of
   preventing any traffic being carried between in the G-ACh consenting
   nodes. transport path.
   Thus a MEP may receive either the management command or an LI message
   first. A good discussion of MEP MUST take the data plane security transport path out of an associated channel
   may be found service immediately
   in [5]. That document also describes some mitigation
   techniques.

   It should be noted that either case, but only sends LI messages itself after it has
   received a management lock command. Thus, a MEP is locked if either
   Lock was requested by management (and, as a result, the G-ACh MEP is essentially connection-oriented
   so injection
   sending LI messages), or modification of control it is receiving LI messages specified in this
   document require from the subversion of remote
   MEP.

   Note that a transit node. Such subversion is
   generally considered hard in MPLS networks, MEP that receives an LI message MUST identify the correct
   transport path and impossible validate the message. The label stack on the
   received message is used to protect
   against at identify the protocol level. Management level techniques are more
   appropriate.

7. IANA Considerations

7.1. Pseudowire Associated Channel Type transport path to be locked:

   - If no matching label binding exists then there is no corresponding
     transport path and the received LI OAM requires a unique Associated Channel Type which message is assigned in error.

   - If the transport path can be identified, but there is no return
     path (for example, the transport path was unidirectional) then the
     lock cannot be applied by
   IANA from the Pseudowire Associated Channel Types Registry.

   Registry:
      Value        Description              TLV Follows  Reference
      -----------  -----------------------  -----------  ---------
      0xHH         LI                       No           (Section 3.1)

8. Acknowledgements

   The authors would like to thank Loa Andersson, Yoshinori Koike,
   D'Alessandro Alessandro Gerardo, Shahram Davari, Greg Mirsky, Yaacov
   Weingarten, Liu Guoman, Matthew Bocci, Stewart Bryant and Adrian
   Farrel receiving MEP.

   - If the transport path is suitable for their valuable comments.

9. References

9.1. Normative References

   [1]   Vigoureux, M., Ward, D., and M. Betts, "Requirements locking but the source MEP-ID
     identifies an unexpected MEP for
         Operations, Administration, and Maintenance (OAM) the MEG to which the receiving MEP
     belongs, the received LI message is in MPLS
         Transport Networks", RFC 5860, May 2010.

   [2]   Bradner, S., "Key words error.

   When an errored LI message is received, the receiving MEP MUST NOT
   apply a lock. A MEP receiving errored LI messages SHOULD perform
   local diagnostic actions (such as counting the messages) and MAY
   log the messages.

   A MEP keeps a transport path locked as long as it is either receiving
   the periodic LI messages or has an in-force Lock command from
   management. (see Section 6.2 for an explanation of unlocking a MEP).
   Note that in some scenarios (such as the use of loopback as described
   in RFCs Section 4) LI messages will not continue to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   D. Allan, et. al., Proactive Connectivity Verification,
         Continuity Check and Remote Defect indication for MPLS be delivered on a
   locked transport path. This is why a transport path is considered
   locked while there is an in-force Lock command from a management
   process regardless of whether LI messages are being received.

6.2. UnLocking a Transport Profile draft-ietf-mpls-tp-cc-cv-rdi-06, work Path

   Unlock is used to request a MEP to bring the previously locked
   transport path back in
         progress, June 2010

   [4]   Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
         Associated Channel", RFC 5586, June 2009.

   [5]   T. Nadeau, C. Pignataro, "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5085, Dec 2007.

9.2. Informative References

   [6]   L. Fang, "Security Framework for MPLS and GMPLS Networks", RFC
         5920, July 2010.

   [7]   S. Bryant, G. Swallow, L. Martini "Pseudowire Emulation Edge-
         to-Edge (PWE3) Control Word for Use over service.

   When a MEP receives an MPLS PSN", RFC
         4385, Feb 2006.

Author's Addresses

    Sami Boutros
   Cisco Systems, Inc.
   Email: sboutros@cisco.com

   Siva Sivabalan
   Cisco Systems, Inc.
   Email: msiva@cisco.com

   Rahul Aggarwal
   Arktan, Inc
   EMail: raggarwa_1@yahoo.com

   Martin Vigoureux
   Alcatel-Lucent.
   Email: martin.vigoureux@alcatel-lucent.com

   Xuehui Dai
   ZTE Corporation.

   Email: dai.xuehui@zte.com.cn

   George Swallow
   Cisco Systems, Inc.
   Email: swallow@cisco.com

   David Ward
   Juniper Networks.
   Email: dward@juniper.net

   Stewart Bryant
   Cisco Systems, Inc.
   Email: stbryant@cisco.com

   Carlos Pignataro
   Cisco Systems, Inc.
   Email: cpignata@cisco.com

   Eric Osborne
   Cisco Systems, Inc.
   Email: eosborne@cisco.com

   Nabil Bitar
   Verizon.
   Email: nabil.bitar@verizon.com

   Italo Busi
   Alcatel-Lucent.
   Email: italo.busi@alcatel-lucent.com

   Lieven Levrau
   Alcatel-Lucent.
   Email: lieven.levrau@alcatel-lucent.com

   Laurent Ciavaglia
   Alcatel-Lucent.
   Email: laurent.ciavaglia@alcatel-lucent.com

   Bo Wu
   ZTE Corporation.
   Email: wu.bo@zte.com.cn
   Jian Yang
   ZTE Corporation.
   Email: yang_jian@zte.com.cn

Full Copyright Statement

   Copyright (c) 2011 IETF Trust and the persons identified Unlocked command from a management process it
   MUST cease sending LI messages. However, as described in Section 6.1,
   if the
   document authors. All rights reserved.

   This document MEP is subject still receiving LI messages, the transport path MUST
   remain out of service. Thus, to BCP 78 and unlock a transport path, the IETF Trust's Legal
   Provisions Relating
   management process has to send an Unlock command to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date MEPs at
   either end.

   When a MEP has been unlocked and has not received an LI message for a
   multiple of
   publication 3.5 times the Refresh Timer on the LI message (or has
   never received an LI message), the MEP unlocks the transport path and
   puts it back into service.

7. Security Considerations

   MPLS-TP is a subset of this document. Please review these documents
   carefully, as they describe your rights MPLS and restrictions with respect so builds upon many of the aspects of
   the security model of MPLS. MPLS networks make the assumption that it
   is very hard to this document. Code Components extracted from this inject traffic into a network, and equally hard to
   cause traffic to be directed outside the network. For more
   information on the generic aspects of MPLS security, see [7].

   This document must
   include Simplified BSD License text as described describes a protocol carried in Section 4.e of the Trust Legal Provisions G-ACh [4], and are so
   is dependent on the security of the G-ACh, itself. The G-ACh is a
   generalization of the Associated Channel defined in [8]. Thus, this
   document relies heavily on the security mechanisms provided without warranty as for the
   Associated Channel and described in the Simplified BSD License.

   All IETF Documents [4] and the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR [8].

   A PARTICULAR PURPOSE.

Intellectual Property Statement

   The IETF takes no position regarding specific concern for the validity or scope of any
   Intellectual Property Rights or other rights G-ACh is that might is can be claimed to
   pertain used to provide a
   covert channel. This problem is wider than the implementation or use scope of the technology described in this
   document or the extent to which any license under such rights
   might or might and does not need to be available; nor does addressed here, but it represent should be
   noted that it has
   made any independent effort to identify any such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat channel provides end-to-end connectivity and any assurances of licenses to SHOULD
   NOT be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights policed by implementers or
   users transit nodes. Thus, there is no simple way of this specification can be obtained from the IETF on-line IPR
   repository at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   preventing any standard or specification contained traffic being carried in an IETF Document.  Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version G-ACh between consenting
   nodes.

   A good discussion of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions data plane security of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to an associated channel
   may be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions of
   these Legal Provisions that are published by third parties, including
   those that are translated into other languages, found in [5]. That document also describes some mitigation
   techniques.

   It should not be
   considered to be definitive versions of these Legal Provions.

   For the avoidance of doubt, each Contributor to the UETF Standards
   Process licenses each Contribution noted that he the G-ACh is essentially connection-oriented
   so injection or she makes as part modification of control messages specified in this
   document require the IETF Standards Process to the IETF Trust pursuant to the
   provisions subversion of RFC 5378. No language a transit node. Such subversion is
   generally considered hard in MPLS networks, and impossible to protect
   against at the contrary, or terms,
   conditions or rights that differ from or protocol level. Management level techniques are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and
   shall be null and void, whether published or posted more
   appropriate.

8. IANA Considerations

8.1. Pseudowire Associated Channel Type

   LI OAM requires a unique Associated Channel Type which is assigned by such
   Contributor, or included with or in such Contribution.

Acknowledgment

   Funding for
   IANA from the RFC Editor function is currently provided by the
   Internet Society. Pseudowire Associated Channel Types Registry.

   Registry:
      Value        Description              TLV Follows  Reference
      -----------  -----------------------  -----------  ---------
      0xHH         LI                       No           [This.I-D]

9. Acknowledgements

   The authors would like to thank Loa Andersson, Yoshinori Koike,
   Alessandro D'Alessandro Gerardo, Shahram Davari, Greg Mirsky, Yaacov
   Weingarten, Liu Guoman, Matthew Bocci, and Adrian Farrel for their
   valuable comments.

10. References

10.1. Normative References

   [1]   Vigoureux, M., Ward, D., and M. Betts, "Requirements for
         Operations, Administration, and Maintenance (OAM) in MPLS
         Transport Networks", RFC 5860, May 2010.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   D. Allan, et. al., Proactive Connectivity Verification,
         Continuity Check and Remote Defect indication for MPLS
         Transport Profile draft-ietf-mpls-tp-cc-cv-rdi-06, work in
         progress, June 2010

   [4]   Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
         Associated Channel", RFC 5586, June 2009.

   [5]   T. Nadeau, C. Pignataro, "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5085, Dec 2007.

   [6]   Busi, I. and Allan, D., "Operations, Administration, and
         Maintenance Framework for MPLS-Based Transport Networks",
         RFC 6371, September 2011

10.2. Informative References

   [7]   L. Fang, "Security Framework for MPLS and GMPLS Networks", RFC
         5920, July 2010.

   [8]   S. Bryant, G. Swallow, L. Martini "Pseudowire Emulation Edge-
         to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC
         4385, Feb 2006.

   [9]   Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
         Transport Profile Data Plane Architecture", RFC 5960, August
         2010.

Editors' Addresses

   Sami Boutros
   Cisco Systems, Inc.
   Email: sboutros@cisco.com

   Siva Sivabalan
   Cisco Systems, Inc.
   Email: msiva@cisco.com

   Rahul Aggarwal
   Arktan, Inc
   EMail: raggarwa_1@yahoo.com

   Martin Vigoureux
   Alcatel-Lucent.
   Email: martin.vigoureux@alcatel-lucent.com

   Xuehui Dai
   ZTE Corporation.
   Email: dai.xuehui@zte.com.cn

Contributing Authors

   George Swallow
   Cisco Systems, Inc.
   Email: swallow@cisco.com

   David Ward
   Juniper Networks.
   Email: dward@juniper.net

   Stewart Bryant
   Cisco Systems, Inc.
   Email: stbryant@cisco.com

   Carlos Pignataro
   Cisco Systems, Inc.
   Email: cpignata@cisco.com

   Eric Osborne
   Cisco Systems, Inc.
   Email: eosborne@cisco.com

   Nabil Bitar
   Verizon.
   Email: nabil.bitar@verizon.com

   Italo Busi
   Alcatel-Lucent.
   Email: italo.busi@alcatel-lucent.com

   Lieven Levrau
   Alcatel-Lucent.
   Email: lieven.levrau@alcatel-lucent.com

   Laurent Ciavaglia
   Alcatel-Lucent.
   Email: laurent.ciavaglia@alcatel-lucent.com

   Bo Wu
   ZTE Corporation.
   Email: wu.bo@zte.com.cn

   Jian Yang
   ZTE Corporation.
   Email: yang_jian@zte.com.cn