Network Working Group Sami Boutros (Ed.)
Internet Draft Siva Sivabalan (Ed.)
Category: Standards Track
Expiration Date: September 2009
George Swallow (Ed.)
Cisco Systems, Inc.
Rahul Aggarwal (Ed.)
Juniper Networks, Inc.
Martin Vigoureux (Ed.)
Alcatel-Lucent
March 9, 2009
Operating MPLS Transport Profile LSP in Loopback Mode
draft-boutros-mpls-tp-loopback-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Boutros, et al. Standards Track [Page 1]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document specifies an extension to MPLS Operation,
Administration, and Maintenance (OAM) to operate an MPLS Transport
Profile(MPLS-TP) Label Switched Path (LSP) in loopback mode for
management purpose. This extension can be used to loop either all
traffic (i.e, data and control traffic) or only specific OAM
traffic at a specified LSR on the path of the MPLS-TP LSP back to
the source.
Boutros, et al. Standards Track [Page 2]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
Contents
1 Introduction .............................................. 4
2 Terminology ............................................... 6
3 MPLS Loopback Mechanism ................................... 6
4 MPLS Loopback Messages .................................... 6
4.1 In-band Message Identification ............................ 6
4.2 Out-of-band Message Identification ........................ 7
4.3 MPLS Loopback Message Format .............................. 7
4.4 Loopback Operations ....................................... 10
4.4.1 Null_Operation ............................................ 10
4.4.2 Lock ...................................................... 10
4.4.3 Unlock .................................................... 10
4.4.4 Set_Full_Loopback and Set_OAM_Loopback .................... 10
4.4.5 Unset_Full_Loopback and Unset_OAM_Loopback ................ 10
4.5 Loopback TLVs ............................................. 11
4.5.1 Authentication TLV ........................................ 11
4.5.2 Source and Target ME TLV .................................. 11
5 Data packets .............................................. 11
6 Network Management Operations ............................. 12
7 Operation ................................................. 13
7.1 General Procedures ........................................ 13
7.2 Sending in-band Loopback messages ......................... 13
7.3 Sending out-of-band Loopback messages ..................... 14
7.4 Example Topology .......................................... 14
7.5 Locking an LSP ............................................ 14
7.6 Unlocking an LSP .......................................... 15
7.7 Setting an LSP into Loopback mode ......................... 16
7.8 Removing an LSP from Loopback mode ........................ 17
7.9 Sending Loopback echo messages ............................ 18
7.10 Operating in Full Loopback Mode ........................... 18
8 Security Considerations ................................... 18
9 IANA Considerations ....................................... 18
10 References ................................................ 18
10.1 Normative References ...................................... 18
10.2 Informative ............................................... 19
11 Authors' Addresses ........................................ 19
Boutros, et al. Standards Track [Page 3]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
1. Introduction
In traditional transport networks, circuits are provisioned across
multiple nodes and service providers have the ability to operate the
transport circuit such as T1 line in loopback mode for management
purposes, e.g., to test or verify connectivity of the circuit up to a
specific node on the path of the circuit, to test the circuit perfor-
mance with respect to delay/jitter, etc. MPLS-TP bidirectional LSP
emulating traditional transport circuits need to provide the same
loopback capability. The mechanism in this document apply to assici-
cated bidirectional paths as defined in [7], which include MPLS-TP
LSPs, pseudowires (PW), and Multisegment PWs.
To describe the loopback functionality, let us assume a bi-direc-
tional MPLS-TP LSP A <---> B <---> C <---> D where A, B, C, and D are
MPLS capable nodes. Also, let us assume that the network operator
requires C to loop, back to A, the packets sent from A. In this exam-
ple, A and D acts as Maintenance End Points (MEPs) and C acts as a
Maintenance Intermediate Point (MIP). The operator can setup the
MPLS-TP LSP into loopback mode such that:
1. C loops all the packets (regardless of whether they are data or
control packets) generated by node A back to A. The packets are
not also forwarded towards D. Similarly, any traffic received by
C from the reverse direction will be dropped. We refer to this
mode "Full Loopback" (FLB).
2. C loops only the OAM control packets (those OAM control packets
will be identified by an ACH code point and will be generated
by node A) back to A, and all other packets from A are sent
towards C. We refer to this mode "OAM Loopback" (OLB).
In FLB mode the operator must take the MPLS-TP LSP out of service
before setting up the MPLS-TP LSP in loopback mode. This is accom-
plished by the MEP establishing the loopback first sending a Lock
command to the remote MEP(s). In the case above, A sends an MPLS
Loopback request message along the MPLS-TP LSP and destined to D with
a lock TLV to lock the MPLS-TP LSP. The message will be intercepted
by D since it is at the end of the LSP. D responds to the lock
request with an MPLS Loopback response message. In OLB mode the oper-
ator need not take MPLS-TP LSP out of service before setting it up
into loopback mode.
In order to set the MPLS-TP LSP in loopback mode, A sends an MPLS
Loopback request message with either a FLB or OLB TLV to the MIP or
MEP where the loopback is to be enabled. In the above example, the
MPLS TTL value is set so that the message will be intercepted by C.
This message contains a request to instruct C to operate the
Boutros, et al. Standards Track [Page 4]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
corresponding MPLS-TP LSP in either Full Loopback mode or OAM Loop-
back mode. C sends an MPLS Loopback response message back to A to
indicate whether or not it has successfully set the MPLS-TP LSP into
the required loopback mode. If the loopback cannot be set, the reply
message would contain an error code. Upon receiving such a reply to
the loopback request, A logs the event and takes further reporting
actions as necessary. If the MPLS-TP LSP was previously locked, A
sends another MPLS Loopback request message to D to unlock it.
In FLB mode the input LSP from the direction of A is directly cross-
connected to the output LSP towards A. All the packets generated by
node A (data and control) are looped back at C, excepting the case of
TTL expiration. When operating the MPLS-TP LSP in OLB, C loops only
OAM packets generated by A with the specific ACH codepoint back to A.
When the loopback operation is no longer required, A sends an MPLS
Loopback request message to remove the loopback and thus restore the
LSP to its original forwarding state. In this example the MPLS TTL
is set such that this message is intercepted by C. It is expected
that C sends a reply back to A to with a return code either ACKing or
NAK the loopback removal request. Upon getting an ACK response to
loopback mode removal request, in FLB mode A sends another MPLS Loop-
back message to unlock the MPLS-TP LSP. The unlock MPLS Loopback
packet is intercepted by D as it is at the end of the MPLS-TP LSP.
The proposed mechanism is based on a new set of messages and TLVs
which can be transported using one of the following methods:
1. Using in-band MPLS Loopback messages which are forwarded as MPLS
packets
(non-IP routing and forwarding based).
2. Using LSP-Ping extensions defined in [4] where IP/UDP packets are
used (IP-based routing and forwarding). The LSP-Ping messages may
be sent
in-band using the codepoint defined in [3].
Method (1) and (2) are referred to as "in-band option" and "LSP-Ping
option" respectively in the rest of the document.
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 [1].
Boutros, et al. Standards Track [Page 5]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
2. Terminology
ACH Associated Channel Header
FLB Full Loopback
LSR Label Switching Router
ME Maintenance Entity
MEP Maintenance End Point
MIP Maintenance Intermediate Point
MPLS-TP MPLS Transport Profile
MPLS-OAM MPLS Operations, Administration and Maintenance
MPLS-TP LSP Bidirectional Label Switch Path representing a
circuit
NMS Network Management System
OLB OAM Loopback
TLV Type Length Value
TTL Time To Live
3. MPLS Loopback Mechanism
For the in-band option, the proposed mechanism uses a new code point
in the Associated Channel Header (ACH) described in [5]. The LSP-
Ping option will be in compliance to specifications [3], [4], and
[6].
4. MPLS Loopback Messages
4.1. In-band Message Identification
In the in-band option, under MPLS label stack of the MPLS-TP LSP, the
ACH with "MPLS-TP Looback" code point indicates that the message is
an MPLS Loopback message.
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 Loopback) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of MPLS-TP Loopback
The first nibble (0001b) indicates the ACH. The version and the
reserved values are both set to 0 as specified in [1]. MPLS-TP loop-
back code point = 0xHH. [HH to be assigned by IANA from the PW
Boutros, et al. Standards Track [Page 6]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
Associated Channel Type registry.]
4.2. Out-of-band Message Identification
[To be added]
4.3. MPLS Loopback Message Format
The format of an MPLS-TP Loopback 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Operation | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Cause Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV's |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS Loopback Message Format
Version
The Version Number is currently 1. (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 Loopback request/response. 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.)
Boutros, et al. Standards Track [Page 7]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
Message Type
Three message types are defined as shown below.
Message Type Description
------------ -------------
0x0 Loopback request
0x1 Loopback response
0x2 Loopback Echo
Operation
Seven operations are defined as shown below. The null
operation is used with the Loopback Echo message. The other
six operations can appear in a Loopback request or Loopback
Response message. Detailed descriptions of the operations
appear in the next section.
Operation Description
--------- -------------
0x0 Null_Operation
0x1 Lock
0x2 Unlock
0x3 Set_Full_Loopback
0x4 Unset_Full_Loopback
0x5 Set_OAM_Loopback
0x6 Unset_OAM_Loopback
Message Length
The total length of any included TLVs.
Sender's Handle
The Sender's Handle is filled in by the sender, and returned
unchanged by the receiver in the MPLS Loopback response message
(if any). There are no semantics associated with this handle,
although a sender may find this useful for matching up requests
with replies.
Boutros, et al. Standards Track [Page 8]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
Message ID
The Message ID is set by the sender of an MPLS Loopback request
message. It MUST be copied unchanged by the receiver in the
MPLS Loopback response message (if any). A sender SHOULD
increment this value on each new message. A retransmitted
message SHOULD leave the value unchanged.
Return code
Value Meaning
----- -------
0 Informational
1 Success
2 Failure
Cause code
Value Meaning
----- -------
0 No cause code
1 Fail to match target MIP/MEP ID
2 Malformed loopback request received
3 One or more of the TLVs is/are unknown
4 Authentication failed
5 MPLS-TP LSP already locked
6 MPLS-TP LSP already unlocked
7 Fail to lock MPLS-TP LSP
8 Fail to unlock MPLS-TP LSP
9 MPLS-TP LSP already in loopback mode
10 MPLS-TP is not in loopback mode
11 Fail to set MPLS-TP LSP in loopback mode
12 Fail to remove MPLS-TP from loopback mode
13 No label binding for received message
The Return code and Cause code only have meaning in a Loopback
Response message. In a Loopback request message the Return code and
Cause code must be set to zero and ignored on receipt.
Boutros, et al. Standards Track [Page 9]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
4.4. Loopback Operations
4.4.1. Null_Operation
The Null_Operation is a place-holder when the Message Type fully
specifies the intended operation.
4.4.2. Lock
The Lock operation is used to take an LSP out of service for mainte-
nance. The Lock operation is carried in an MPLS Loopback request
message sent from a MEP to a trail-end MEP of the LSP to request that
the LSP be taken out of service. In response, the Lock operation is
carried in an Loopback response message sent from the trail-end MEP
back to the originating MEP to report the result.
4.4.3. Unlock
The Unlock operation is used to restore a previously locked LSP to
service. The Unlock operation is carried in an MPLS Loopback request
message sent from a MEP to a trail-end MEP of the LSP to request that
the LSP be restored to service. In response, the Unlock operation is
carried in an Loopback Response message sent from the trail-end MEP
back to the originating MEP to report the result.
4.4.4. Set_Full_Loopback and Set_OAM_Loopback
The Set_Full_Loopback and Set_OAM_Loopback are used to set an LSP
into FLB mode and OLB mode respectively. These operations are car-
ried in an MPLS Loopback request message sent from a MEP to either a
MIP or a MEP of the LSP to request that the LSP be set into FLB mode
and OLB mode respectively. In response, these operations are carried
in an Loopback response message sent from the MIP or MEP, where the
Loopback operation has been requested, back to the originating MEP to
report the result.
4.4.5. Unset_Full_Loopback and Unset_OAM_Loopback
The Unset_Full_Loopback and Unset_OAM_Loopback are used to remove a
previously set FLB mode and OLB mode respectively. These operations
are carried in an MPLS Loopback request message sent from a MEP to a
MIP or a MEP to request that a previously set loopback be removed.
In response, these operations are carried in an Loopback response
message sent from the MIP or MEP, where the Loopback operation has
Boutros, et al. Standards Track [Page 10]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
been requested, back to the originating MEP to report the result.
4.5. Loopback TLVs
4.5.1. Authentication TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mechanisms similar to PPP Chap can be used to authenticate the MPLS
OAM Loopback request. A variable length key can be carried in an
optional authentication TLV which can be included in the MPLS Loop-
back request message. The use of authentication key is outside the
scope of the document.
4.5.2. Source and Target ME TLV
The Source and Target ME is used when out-of-band messages are used.
The TLV is simply a container. The TLVs defined in [8] are used as
sub-TLVs of this TLV.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Data packets
When an LSP operates in FLB mode, data packets sent from the node on
which the sender MEP resides, will be looped back to that same node.
Thus any packet format is permitted.
[Do we want to standardize a format for mesurement purposes. If so
the following format is suggested.]
In order for the sender MEP node to make sure that no data packets
are dropped, each data MPLS packets may contain a sequence-id right
Boutros, et al. Standards Track [Page 11]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
after the label stack. A time-stamp fields in the datapackets can
help calculate the Round trip delay of datapackets. The Local Time-
Stamp is set by the sender, and can be used to caluculate the round
trip delay after the message is looped back.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label with EOS bit set |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Arbitrary Padding |
: :
| Arbitrary Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Network Management Operations
[This section is incomplete - should it even be in this document?]
An operator should be able to provision any given LSR to:
1. Lock/Unlock any MPLS-TP LSP.
2. set any MPLS-TP LSP into loopback mode (either FLB or OLB).
3. send MPLS Loopback packets from a MEP and notify NMS when MPLS
Loopback
response arrives.
When an NMS is used to provision any of the above the functionality,
the corresponding MPLS Loopback message need not used.
Boutros, et al. Standards Track [Page 12]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
7. Operation
7.1. General Procedures
When placing an LSP into FLB mode, the operation MUST first be pre-
ceded by a Lock operation. A Lock operation is not required for OLB
mode.
[To be added: text about construction of request and response mes-
sages including text about sender's handle, message ID]
7.2. Sending in-band Loopback messages
When sending an MPLS Loopback message in-band, the message is
prepended with the Source MEP and Target MIP/MEP ID according to the
procedures defined in [8].
The ACH is then prepended with the ACH Channel ID set to 0xHH (TBD).
The label stack is then applied. In the case of a PW, this consists
of just the outgoing label(s) for the PW. (Note - need to deal with
entropy label here).
For other MPLS-TP LSPs the label stack consists of the label repre-
senting the outbound side of the bi-directional path followed by the
GAL.
The TTL of the topmost label is set as follows. If the target ME is
a MIP, the TTL MUST be set to the exact number of hops required to
reach that MIP. If the target ME is a MEP, the value MUST be set to
at least the number of hops required to reach that MIP. For most
operations where the target is a MEP, the TTL MAY be set to 255.
However, to remove a MEP from FLB mode, the sending MEP MUST set the
TTL to the exact number of hops required to reach the MEP (if the TTL
were set higher, the MPLS Loopback request message would be looped
back toward the sender). It is RECOMMENDED that when setting a MEP
into FLB mode, the TTL be set to the exact number of hops required to
reach the MEP.
Boutros, et al. Standards Track [Page 13]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
7.3. Sending out-of-band Loopback messages
[To be written]
7.4. Example Topology
The next four sections discuss the proceedures for Locking, Unlock-
ing, setting an LSP into loopback, and removing the loopback. The
description is worded using an example. Assume an MPLS-TP LSP tra-
verses nodes A <--> B <--> C <--> D. We will refer to the Mainte-
nance Entities involved as MEP-A, MIP-B, MIP-C, and MEP-D respec-
tively. Suppose a maintenance operation invoked at node A requires a
loopback be set at node C. To invoke FLB mode at node C, A would
first need to lock the LSP. The it may proceed to set the loopback
at C. Following the loopback operation, A would need to remove the
loopback at C and finally unlock the LSP.
The following sections describe MEP-A setting and unsetting a lock at
MEP-D and then setting and removing a loopback at MIP-C.
7.5. Locking an LSP
1. MEP-A sends an MPLS Loopback request message with the Lock
Operation indicated. Optionally, an authentication TLV MAY be
included.
2. Upon receiving the MPLS Loopback request message, D uses the
received label stack to identify the LSP. If no label binding
exists or there is no associated LSP back to the originator, the
event is logged. Processing ceases. Otherwise the message is
delivered to the target MEP.
a. if the source MEP-ID does not match, the event is logged and
processing ceases.
b. if the target MEP-ID does not match, MEP-D sends a
response with a return code of 2 and a cause code 1.
MEP-D then examines the message, and:
c. if the message is malformed, it sends a response with a return
code of 2 and a cause code 2 back to MEP-A.
d. if message authentication fails, it MAY send a response with a
return code of 2 and a cause code 4 back to MEP-A.
Boutros, et al. Standards Track [Page 14]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
e. if any of the TLVs is not known, it sends a response with a
return code of 2 and a cause code 3 back to MEP-A. It may also
include the unknown TLVs.
f. if the MPLS-TP is already locked, it sends a response with
return code of 1 (success) and a cause code 5 back to MEP-A.
g. if the MPLS-TP is not already locked and cannot be locked, it
sends a response with a return code of 2 and a cause code 7
back to A.
h. if the MPLS-TP is successfully locked, it sends a response with
an return code of 1 (success) and a cause code 0 back to MEP-A.
The response is sent using an MPLS Loopback reponse message.
An authentication TLV MAY be included.
7.6. Unlocking an LSP
1. MEP-A sends an MPLS Loopback request message with the Lock
Operation indicated. Optionally, an authentication TLV MAY be
included.
2. Upon receiving the MPLS Loopback request message, D uses the
received label stack to identify the LSP. If no label binding
exists or there is no associated LSP back to the originator, the
event is logged. Processing ceases. Otherwise the message is
delivered to the target MEP.
a. if the source MEP-ID does not match, the event is logged and
processing ceases.
b. if the target MEP-ID does not match, MEP-D sends a
response with a return code of 2 and a cause code 1.
MEP-D then examines the message, and:
c. if the message is malformed, it sends a response with a return
code of 2 and a cause code 2 back to MEP-A.
d. if message authentication fails, it MAY send a response with a
return code of 2 and a cause code 4 back to MEP-A.
e. if any of the TLVs is not known, it sends a response with a
return code of 2 and a cause code 3 back to MEP-A. It may also
include the unknown TLVs.
Boutros, et al. Standards Track [Page 15]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
f. if the LSP is locked and cannot be unlocked, it sends a
response
with a return code of 2 and a cause code 8 back to MEP-A.
g. if the LSP is successfully unlocked, it sends a response an
return code of 1 (success) and a cause code 0 back to MEP-A.
The response is sent using an MPLS Loopback reponse message.
An authentication TLV MAY be included.
7.7. Setting an LSP into Loopback mode
1. MEP-A sends an MPLS Loopback request message with the
Set_Full_Loopback or Set_OAM_Loopback Operation indicated.
Optionally, an authentication TLV MAY be included.
2. Upon intercepting the MPLS Loopback request message via TTL
expiration, C uses the received label stack to identify the LSP.
If no label binding exists or there is no associated LSP back to
the originator, the event is logged. Processing ceases.
Otherwise the message is delivered to the target MIP/MEP - in this
case MIP-C.
a. if the source MEP-ID does not match, the event is logged and
processing ceases.
b. if the target MIP-ID does not match, MIP-C sends a
response with a return code of 2 and a cause code 1.
MIP-C then examines the message, and:
c. if the message is malformed, it sends a response with a return
code of 2 and a cause code 2.
d. if the message authentication fails, it sends a response with
a return code of 2 and a cause code 4.
e. if any of the TLV is not known, C sends a response with a
return code of 2 and a cause code 3. It may also include the
unknown TLVs.
f. if the MPLS-TP is already in the requested loopback mode (in
this case FLB mode), it sends a response with return code of 1
(success) and a cause code 9.
g. if the MPLS-TP is not already in the requested loopback mode
(in this case FLB mode) and that loopback mode cannot be set,
Boutros, et al. Standards Track [Page 16]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
it sends a response with a return code of 2 and a cause code 11
back to A.
h. if the MPLS-TP is successfully programmed into the requested
loopback mode (in FLB mode), it sends a response with a return
code of 1 (success) and a cause code of 0.
The response is sent using an MPLS Loopback reponse message.
An authentication TLV MAY be included.
7.8. Removing an LSP from Loopback mode
1. MEP-A sends an MPLS Loopback request message with the
Unset_Full_Loopback or Unset_OAM_Loopback Operation indicated.
Optionally, an authentication TLV MAY be included.
2. Upon intercepting the MPLS Loopback request message via TTL
expiration, C uses the received label stack to identify the LSP.
If no label binding exists or there is no associated LSP back to
the originator, the event is logged. Processing ceases.
Otherwise the message is delivered to the target MIP/MEP - in this
case MIP-C.
a. if the source MEP-ID does not match, the event is logged and
processing ceases.
b. if the target MIP-ID does not match, MIP-C sends a
response with a return code of 2 and a cause code 1.
MIP-C then examines the message, and:
c. if the message is malformed, it sends a response with a return
code of 2 and a cause code 2.
d. if the message authentication fails, it sends a response with
a return code of 2 and a cause code 4.
e. if any of the TLV is not known, C sends a response with a
return code of 2 and a cause code 3. It may also include the
unknown TLVs.
f. if the MPLS-TP is not in loopback mode, it sends a response
with a return code of 2 and a cause code 10.
g. if the MPLS-TP is successfully changed from loopback mode to
normal mode of operation, it sends a reply with a return code
of 1 (success) and a cause code of 0.
Boutros, et al. Standards Track [Page 17]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
The response is sent using an MPLS Loopback reponse message.
An authentication TLV MAY be included.
7.9. Sending Loopback echo messages
[To be written]
7.10. Operating in Full Loopback Mode
[To be written]
8. Security Considerations
The security considerations for the authentication TLV need further
study.
9. IANA Considerations
TBD
10. References
10.1. Normative References
[1] Bradner. S, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997.
[2] L. Martini, et. al., "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC4447, April, 2006.
[3] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity
Verification (VCCV): A Control Channel for Pseudowires ",
RFC 5085, December 2007.
[4] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label Switched
(MPLS) Data Plane Failures", RFC 4379, February 2006.
Boutros, et al. Standards Track [Page 18]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
10.2. Informative
[5] M. Bocci, et. al., "MPLS Generic Associated Channel",
draft-bocci-mpls-tp-gach-gal-00.txt, work in progress, October
24,
2008.
[6] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire
Emulation Edge-to-Edge (PWE3) ", RFC5254, October 2008.
[7] M. Bocci, et. al., "A Framework for MPLS in Transport Networks",
draft-ietf-mpls-tp-framework-00, November 2008.
[8] S. Boutros, et. al., " Definition of ACH TLV Structure",
draft-bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January
2009.
11. Authors' Addresses
Sami Boutros
Cisco Systems, Inc.
Email: sboutros@cisco.com
Siva Sivabalan
Cisco Systems, Inc.
Email: msiva@cisco.com
George Swallow
Cisco Systems, Inc.
Email: swallow@cisco.com
David Ward
Cisco Systems, Inc.
Email: wardd@cisco.com
Stewart Bryant
Cisco Systems, Inc.
Email: stbryant@cisco.com
Carlos Pignataro
Cisco Systems, Inc.
Email:cpignata@cisco.com
Rahul Aggarwal
Juniper Networks
EMail: rahul@juniper.net
Boutros, et al. Standards Track [Page 19]
Internet Draft draft-boutros-mpls-tp-loopback-02.txt March 2009
Nabil Bitar
Verizon
Email: nabil.bitar@verizon.com
Martin Vigoureux
Alcatel-Lucent
Email: martin.vigoureux@alcatel-lucent.com
Italo Busi
Alcatel-Lucent
Email:italo.busi@alcatel-lucent.it
Lieven Levrau
Alcatel-Lucent
Email:llevrau@alcatel-lucent.com
Laurent Ciavaglia
Alcatel-Lucent
Email:laurent.ciavaglia@alcatel-lucent.com
Boutros, et al. Standards Track [Page 20]
Boutros, et al. Standards Track [Page 22]