draft-ietf-mpls-tp-li-lb-01.txt   draft-ietf-mpls-tp-li-lb-02.txt 
Network Working Group Sami Boutros (Ed.) Network Working Group Sami Boutros (Ed.)
Internet Draft Siva Sivabalan (Ed.) Internet Draft Siva Sivabalan (Ed.)
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: September 1, 2011 Expires: December 5, 2011
Rahul Aggarwal (Ed.) Rahul Aggarwal (Ed.)
Juniper Networks, Inc. Juniper Networks, Inc.
Martin Vigoureux (Ed.) Martin Vigoureux (Ed.)
Alcatel-Lucent Alcatel-Lucent
Xuehui Dai (Ed.) Xuehui Dai (Ed.)
ZTE Corporation ZTE Corporation
March 1, 2011 June 5, 2011
MPLS Transport Profile Lock Instruct and Loopback Functions MPLS Transport Profile Lock Instruct and Loopback Functions
draft-ietf-mpls-tp-li-lb-01.txt draft-ietf-mpls-tp-li-lb-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 1, 2011. This Internet-Draft will expire on December 5, 2011.
Abstract Abstract
This document specifies an extension to MPLS Operation, This document specifies an extension to MPLS Operation,
administration, and Maintenance (OAM) to operate an Label Switched administration, and Maintenance (OAM) to operate an Label Switched
Path (LSP), bi-directional RSVP-TE tunnels, Pseudowires (PW), or Path (LSP), bi-directional RSVP-TE tunnels, Pseudowires (PW), or
Multi-segment PWs in loopback mode for management purpose in an MPLS Multi-segment PWs in loopback mode for management purpose in an MPLS
based Transport. This extension includes mechanism to lock and based Transport. This extension includes mechanism to lock and
unlock MPLS-TP Tunnels (i.e. data and control traffic) and can be unlock MPLS-TP Tunnels (i.e. data and control traffic) and can be
used to loop all traffic (i.e, data and control traffic) at a used to loop all traffic (i.e, data and control traffic) at a
specified LSR on the path of the LSP in an MPLS based Transport specified LSR on the path of the LSP in an MPLS based Transport
Network back to the source. However, the mechanisms are intended to Network back to the source. However, the mechanisms are intended to
be applicable to other aspects of MPLS as well. be applicable to other aspects of MPLS as well.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Terminology....................................................5 2. Terminology....................................................5
3. Loopback/Lock Mechanism........................................5 3. Loopback/Lock Mechanism........................................5
3.1. In-band Message Identification............................5 3.1. In-band Message Identification............................5
3.2. LI-LB Message Format......................................6 3.2. LI-LB Message Format......................................6
3.3. LSP Ping Extensions.......................................8 3.3. Return codes..............................................7
3.3.1. Lock Request TLV.....................................8 3.4. Cause codes...............................................7
3.3.2. Unlock Request TLV...................................8 3.5. Authentication TLV........................................8
3.3.3. Loopback Request TLV.................................8 3.6. LSP Ping Extensions.......................................9
3.3.4. Loopback Removal TLV.................................9 3.6.1. LI-LB Request TLV....................................9
3.3.5. Response TLV.........................................9 3.6.2. LI-LB Response TLV...................................9
3.3.6. Authentication TLV..................................10 4. Loopback/Lock Operations.......................................9
4. Loopback/Lock Operations......................................10
4.1. Lock Request.............................................10 4.1. Lock Request.............................................10
4.2. Unlock Request...........................................10 4.2. Unlock Request...........................................10
4.3. Loopback Request.........................................11 4.3. Loopback Request.........................................10
4.4. Loopback Removal.........................................11 4.4. Loopback Removal.........................................11
5. Data packets..................................................11 5. Data packets..................................................11
6. Operation.....................................................11 6. Operation.....................................................11
6.1. General Procedures.......................................11 6.1. General Procedures.......................................11
6.2. Example Topology.........................................12 6.2. Example Topology.........................................11
6.3. Locking an LSP...........................................12 6.3. Locking an LSP...........................................12
6.4. Unlocking an LSP.........................................13 6.4. Unlocking an LSP.........................................13
6.5. Interoperability with Lock Instruct OAM function.........14 6.5. Setting an LSP into Loopback mode........................14
6.6. Setting an LSP into Loopback mode........................14 6.6. Removing an LSP from Loopback mode.......................15
6.7. Removing an LSP from Loopback mode.......................15
7. Security Considerations.......................................16 7. Security Considerations.......................................16
8. IANA Considerations...........................................16 8. IANA Considerations...........................................16
8.1. Pseudowire Associated Channel Type.......................16 8.1. Pseudowire Associated Channel Type.......................16
8.2. New LSP Ping TLV types...................................16 8.2. New LSP Ping TLV types...................................16
9. Acknowledgements..............................................17 9. Acknowledgements..............................................16
10. References...................................................17 10. References...................................................16
10.1. Normative References....................................17 10.1. Normative References....................................16
10.2. Informative References..................................17 10.2. Informative References..................................17
Author's Addresses...............................................18 Author's Addresses...............................................17
Full Copyright Statement.........................................19 Full Copyright Statement.........................................19
Intellectual Property Statement..................................20 Intellectual Property Statement..................................19
1. Introduction 1. Introduction
In traditional transport networks, circuits are provisioned across In traditional transport networks, circuits are provisioned across
multiple nodes and service providers have the ability to operate the multiple nodes and service providers have the ability to operate the
transport circuit such as T1 line in loopback mode for management 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 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 specific node on the path of the circuit, to test the circuit
performance with respect to delay/jitter, etc. We need to provide the performance with respect to delay/jitter, etc. This document provides
same loopback capability for the bi-directional LSPs in MPLS based the same loopback capability for the bi-directional LSPs in MPLS
Transport Networks emulating traditional transport circuits. The based Transport Networks emulating traditional transport circuits.
mechanisms in this document apply to co-routed bidirectional paths as The mechanisms in this document apply to co-routed bidirectional
defined in [7], which include LSPs, bi-directional RSVP-TE tunnels, paths as defined in [7], which include LSPs, bi-directional RSVP-TE
Pseudowires (PW), and Multi-segment PWs in MPLS based Transport tunnels, Pseudowires (PW), and Multi-segment PWs in MPLS based
Networks. However, the mechanisms are intended to be applicable to Transport Networks. However, the mechanisms are intended to be
other aspects of MPLS as well. applicable to other aspects of MPLS as well.
This document specifies how to operate the Lock and Loopback This document specifies how to operate the Lock and Loopback
functions over the Generic Associated Channel (GACh) and over LSP- functions over both the Generic Associated Channel (GACh) and over
Ping. LSP-Ping is possible to run over the GACh or when IP-addressing LSP-Ping. LSP-Ping itself can run either over the GACh or using
is available it is possible to run it natively. The first two cases native IP addressing; the manner in which LSP-Ping is transported in
will work for MPLS based Transport Networks without IP-addressing. an MPLS-TP network is out of the scope of this document.
To describe the loopback functionality, let us assume a bi-
directional LSP in a MPLS based Transport Network 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, so
that all the test data packets sent from A over that LSP. In this
example, A and D acts as Maintenance End Points (MEPs) and C acts as
a Maintenance Intermediate Point (MIP). The operator can setup the
LSP into loopback mode such that C loops all MPLS encapsulated
packets (regardless of whether they are data or control packets) that
A as an ingress LSR puts on the LSP back to A. The packets MUST NOT
be forwarded towards D. Similarly, any traffic received by C from the
reverse direction MUST be dropped.
For any LSP in a MPLS based Transport Network the operator must take This document uses a sample topology to describe the lock instruct
the LSP out of service before setting up the LSP in loopback mode. and loopback functions. This sample topology comprises four MPLS-TP
This is accomplished by the MEP establishing the loopback first nodes [A---B---C---D]. There is an LSP from A to D, and thus A and D
sending a Lock command to the remote MEP(s). In the case above, A are MEPs and B and C are MIPs. Unless otherwise specified, the
sends a Lock request message along the LSP and destined to D to lock operator desires to lock the LSP (this is done on A and D, by
the LSP. The message will be intercepted by D since it is at the end definition) and loop the LSP at C.
of the LSP. D responds to the lock request with a reply message
specifying whether it can take the LSP out of service or not.
In order to set the LSP in loopback mode, A sends a Loopback request That is, the desired behavior is that all packets transmitted by A on
message to the MIP or MEP where the loopback is to be enabled. In the this locked and looped LSP arrive at C from B and are encapsulated in
above example, the MPLS TTL value is set so that the message will be the D->A direction by C such that these packets reach A.
intercepted by C.
The request message contains a Loopback request to instruct C to Locking and looping an LSP is a two-step process. The first step is
operate an indicated LSP in Loopback mode. C responds to the Loopback to lock the LSP so that it is not made available to carry user
request with a reply message back to A to indicate whether or not it traffic. The locking of an LSP is managed by the two MEPs of an LSP -
has successfully set the LSP into the loopback mode. in this example, A and D. Locking is controlled by one of the MEPs;
this example uses A. A sends a Lock request message to D along the
LSP, either in the GACh or in LSP-Ping. This message will be
received by D as it is the far-end MEP for that LSP. D responds to
the lock request with an ACK or NACK; the ACK indicates that D has
taken the LSP out of service (i.e. Locked the LSP) and the NACK
indicates that D cannot comply with the Lock request. In general, if
a message (e.g. Lock request, Loopback request) cannot be complied
with, the node which received the request replies with a NACK and a
cause code; the details of error message processing are discussed
later in this document.
If the loopback cannot be set, the reply message would contain an Once A has received the ACK to its Lock request, A is then allowed to
error code. Upon receiving a reply with an error code to the loopback put the LSP in Loopback mode. In order to set the LSP in Loopback
request, A logs the event and takes further reporting actions as mode, A sends a Loopback request message to the MIP or MEP where A
necessary. If the LSP was previously locked, A sends another request desired the loopback to be enabled. In this example, A desires to
message to D to unlock it. set the loopback at C, although note that it is possible to A to set
the loopback at any node downstream of A (e.g. B, C, D). The TTL on
the Loopback request message is set by A such that the TTL expires
when it reaches the node where A wants the loopback to be set (in
this case, C). C responds to the Loopback request with a reply
message (ACK/NACK) back to A to indicate whether it has successfully
set the LSP into the Loopback mode.
If the loopback request can be performed, the input LSP from the If A receives an ACK from its Loopback request, the LSP is now in
direction of A is directly cross-connected to the output LSP towards Loopback mode. A is free to send any test packets down this LSP as
A. All the packets generated by node A (data and control) are looped it sees fit. These packets MUST NOT be forwared towards D. As the
back at C, excepting the case of TTL expiration. LSP is locked, D MUST NOT transmit any traffic on the LSP in the
reverse direction (that is, D->A). Any traffic received by C from
the reverse direction MUST be dropped and MAY be logged, as the
receipt of traffic by C in the D->A direction indicates an error.
When the loopback operation is no longer required, A sends a request When A desires to remove the LSP from Loopback state, it begins to
message to remove the loopback and thus restore the LSP to its reverse the Loopback and Lock. This is a two-step process; first A
original forwarding state. In this example the MPLS TTL is set such removes the Loopback from C, then A removes the Lock from D. This
that this message is intercepted by C. It is expected that C sends a process is similar to the process of establishing Lock and Loopback
reply back to A to with a return code either ACKing or NAK the in the first place. A sends a Loopback Remove message to C using the
loopback removal request. Upon getting an ACK response to loopback TTL method described above, and C ACKs or NACKs the Loopback Remove.
mode removal request, A sends another request message to unlock the Once A receives the Loopback Remove ACK from C, A sends a Lock Remove
LSP. The packet is intercepted by D as it is at the end of the LSP. message to D. D must ACK or NACK this message. Once A receives the
Lock Remove ACK from D, the LSP is brought back into normal
operation.
The proposed mechanism is based on a new set of messages and TLVs The proposed mechanism is based on a new set of messages and TLVs
which can be transported using one of the following methods: which can be transported using one of the following methods:
(1) An in-band MPLS message transported using a new ACH code point, (1) An in-band MPLS message transported using a new ACH code point,
the message will have different types to perform the loopback the message will have different types to perform the loopback
request/remove and Lock/unlock functions, and may carry new set of request/remove and Lock/unlock functions, and may carry new set of
TLVs. TLVs.
(2) A new set of TLVs which can be transported using LSP-Ping (2) A new set of TLVs which can be transported using LSP-Ping
extensions defined in [4], and in compliance to specifications [5]. extensions defined in [4], and in compliance to specifications [5].
Method (1) and (2) are referred to as "in-band option" and "LSP-Ping Method (1) and (2) are referred to as "in-band option" and "LSP-Ping
option" respectively in the rest of the document. option" respectively in the rest of the document.
Conventions used in this document Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [3]. document are to be interpreted as described in RFC-2119 [3].
2. Terminology 2. Terminology
ACH: Associated Channel Header ACH: Associated Channel Header
LSR: Label Switching Router LSR: Label Switching Router
skipping to change at page 7, line 32 skipping to change at page 7, line 24
There are no semantics associated with this handle, although a sender There are no semantics associated with this handle, although a sender
may find this useful for matching up requests with replies. may find this useful for matching up requests with replies.
Message ID Message ID
The Message ID is set by the sender of an MPLS request message. It The Message ID is set by the sender of an MPLS request message. It
MUST be copied unchanged by the receiver in the MPLS response message MUST be copied unchanged by the receiver in the MPLS response message
(if any). A sender SHOULD increment this value on each new message. (if any). A sender SHOULD increment this value on each new message.
A retransmitted message SHOULD leave the value unchanged. A retransmitted message SHOULD leave the value unchanged.
Return code The Return code and Cause code only have meaning in a Response
message. In a request message the Return code and Cause code must be
set to zero and ignored on receipt. Return codes and cause codes are
described in the following Sections.
3.3. Return codes
Value Meaning Value Meaning
----- ------- ----- -------
0 Informational 0 Informational
1 Success 1 Success
2 Failure 2 Failure
Cause code 3.4. Cause codes
Value Meaning
----- -------
0 No cause code
1 Fail to match target MIP/MEP ID
2 Malformed request received
3 One or more of the TLVs is/are unknown
4 Authentication failed
5 LSP/PW already locked
6 LSP/PW already unlocked
7 Fail to lock LSP/PW
8 Fail to unlock LSP/PW
9 LSP/PW already in loopback mode
10 LSP/PW is not in loopback mode
11 Fail to set LSP/PW in loopback mode
12 Fail to remove LSP/PW from loopback mode
13 No label binding for received message
The Return code and Cause code only have meaning in a Response Value Meaning
message. In a request message the Return code and Cause code must be ----- -------
set to zero and ignored on receipt. 0 Success
1 Fail to match target MIP/MEP ID
2 Malformed LI-LB request received
3 One or more of the TLVs is/are unknown
4 Authentication failed
5 LSP/PW already locked
6 LSP/PW already unlocked
7 Fail to lock LSP/PW
8 Fail to unlock LSP/PW
9 LSP/PW already in loopback mode
10 LSP/PW is not in loopback mode
11 Fail to set LSP/PW in loopback mode
12 Fail to remove LSP/PW from loopback mode
13 No label binding for received message
14 Authentication required but not received.
3.3. LSP Ping Extensions Note that in the case of cause code 3, the unknown TLV can also be
optionally included in the response. For failure responses with multiple
causes only the first cause code can be included.
3.3.1. Lock Request TLV 3.5. Authentication TLV
0 1 2 3 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 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = TBD | length = 0 | | type = TBD | Length = 0xx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A MEP includes a Lock Request TLV in the MPLS LSP Ping echo request
message to request the MEP on the other side of the LSP to take the
LSP out of service.
3.3.2. Unlock Request 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 = 0 | | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unlock Request TLV is sent from the MEP which has previously sent The PPP CHAP described in [9] will be used to authenticate the LI-LB
lock request. Upon receiving the LSP Ping Echo request message with request.
the unlock request TLV, the receiver MEP brings the LSP back in
service.
3.3.3. Loopback Request TLV The variable length value carried in the optional authentication TLV,
will include the Packet Format described in section 3.2 of [9].
0 1 2 3 The optional authentication TLV can be included in the MPLS OAM LSP
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 Ping echo messages containing a LI-LB request TLV or in the inband
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LI-LB Message. When an authentication TLV is present in the Request
| type = TBD | length = 0 | message the CHAP procedures described in section 3.2 of [9] MUST be
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ followed.
When a MEP wants to put an LSP in loopback mode, it sends a MPLS LSP The CHAP packets will be transmitted by the authenticator using LI-LB
Ping echo request message with Loopback Request TLV. The message can Request or response messages, responses to the authentication
be intercepted by either a MIP or a MEP depending on the MPLS TTL protocol messages will be transmitted using LI-LB request or response
value. The receiver puts in corresponding LSP in loopback mode. messages.
3.3.4. Loopback Removal TLV If the CHAP negotiation results in a failure, the authenticator or
the sender of the request message MUST stop requesting the LI-LB
function.
0 1 2 3 A receiver of an LI-LB request, MAY send an error "Authentication
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 required but not received", if the optional authentication TLV is not
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ included in the LI-LB request.
| type = TBD | length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When loopback mode operation of an LSP is no longer required, the MEP 3.6. LSP Ping Extensions
that previously sent the MPLS LSP Ping echo request message with a
loopback TLV, sends another MPLS LSP Ping echo request message with a
Loopback Removal TLV. The receiver MEP changes the LSP from loopback
mode to normal mode of operation.
3.3.5. Response TLV 3.6.1. LI-LB Request TLV
0 1 2 3 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 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 = 0x1 | | type = TBD | length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ReturnCode | | Operation |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+
Return code Operation Description
Value Meaning --------- -------------
----- ------- 0x1 Lock
0 Success 0x2 Unlock
1 Fail to match target MIP/MEP ID 0x3 Set_Loopback
2 Malformed loopback request received 0x4 Unset_Loopback
3 One or more of the TLVs is/are unknown
4 Authentication failed
5 LSP/PW already locked
6 LSP/PW already unlocked
7 Fail to lock LSP/PW
8 Fail to unlock LSP/PW
9 LSP/PW already in loopback mode
10 LSP/PW is not in loopback mode
11 Fail to set LSP/PW in loopback mode
12 Fail to remove LSP/PW from loopback mode
13 No label binding for received message
Note that in the case of error code 3, the unknown TLV can also be A MEP includes a LI-LB Request TLV in the MPLS LSP Ping echo request
optionally included in the response TLV. message to request the MEP on the other side of the LSP toperform
Lock/Unlock and Set/Unset Loopback operations. Only one LI-LB request
TLV can be present in an LSP Ping Echo request message.
3.3.6. Authentication TLV 3.6.2. LI-LB Response TLV
0 1 2 3 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 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 | | type = TBD | Length = 0x3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Operation | ReturnCode | CauseCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mechanisms similar to PPP Chap can be used to authenticate the Only one LI-LB response TLV can be present in an LSP Ping Echo
Loopback request. A variable length key can be carried in an optional request message.
authentication TLV which can be included in the MPLS OAM LSP Ping
echo request message containing a loopback request TLV or the LI-LB
Message. The use of authentication key is outside the scope of the
document.
4. Loopback/Lock Operations 4. Loopback/Lock Operations
When performing a Lock or Loopback function, the reply to a message
MUST use the same method as the original message. That is, if a node
requests lock or loopback using LSP Ping then any replies to that
request must also use LSP Ping; if a node requests lock or loopback
using in-band, any replies to that request must use in-band. It is
permissible to use different methods for the lock and the loopback
functions on a given LSP. For example, a node can lock an LSP using
the LSP Ping method and then can loop the LSP using the in-band
method, or vice versa.
An ACK response of a request will be a response message with return
code 1 (success) and cause code 0, while a NACK response will have a
return code 2 (failure) and the corresponding cause code.
4.1. Lock Request 4.1. Lock Request
Lock Request is used to request a MEP to take an LSP out of service Lock Request is used to request a MEP to take an LSP out of service
so that some form of maintenance can be done. so that some form of maintenance can be done.
The receiver MEP MUST send either an ACK or a NAK response to the The receiver MEP MUST send either an ACK or a NAK response to the
sender MEP. Until the sender MEP receives an ACK, it MUST NOT assume sender MEP. Until the sender MEP receives an ACK, it MUST NOT assume
that the receiver MEP has taken the LSP out of service. A receiver that the receiver MEP has taken the LSP out of service. A receiver
MEP sends an ACK only if it can successfully lock the LSP. Otherwise, MEP sends an ACK only if it can successfully lock the LSP. Otherwise,
it sends a NAK. it sends a NAK.
The receiver MEP once locked, MUST discard all received traffic.
4.2. Unlock Request 4.2. Unlock Request
The Unlock Request is sent from the MEP which has previously sent The Unlock Request is sent from the MEP which has previously sent
lock request. Upon receiving the unlock request message, the receiver lock request. Upon receiving the unlock request message, the receiver
MEP brings the LSP back in service. MEP brings the LSP back in service.
The receiver MEP MUST send either an ACK or a NAK response to the The receiver MEP MUST send either an ACK or a NAK response to the
sender MEP. Until the sender MEP receives an ACK, it MUST NOT assume sender MEP. Until the sender MEP receives an ACK, it MUST NOT assume
that the LSP has been put back in service. A receiver MEP sends an that the LSP has been put back in service. A receiver MEP sends an
ACK only if the LSP has been unlocked, and unlock operation is ACK only if the LSP has been unlocked, and unlock operation is
skipping to change at page 11, line 35 skipping to change at page 11, line 22
The receiver MEP or MIP MUST send either an ACK or NAK response to The receiver MEP or MIP MUST send either an ACK or NAK response to
the sender MEP. An ACK response is sent if the LSP is already in the sender MEP. An ACK response is sent if the LSP is already in
loopback mode, and if the LSP is successfully put back in normal loopback mode, and if the LSP is successfully put back in normal
operation mode. Otherwise, a NAK response is sent. Until an ACK operation mode. Otherwise, a NAK response is sent. Until an ACK
response is received, the sender MEP MUST NOT assume that the LSP is response is received, the sender MEP MUST NOT assume that the LSP is
put back in normal operation mode. put back in normal operation mode.
5. Data packets 5. Data packets
Data packets sent from the sender MEP will be looped back to that Data packets sent from the sender MEP will be looped back to that
sender MEP. The use of data packets to measure packet loss, delay and sender MEP. OAM packets not intercepted by TTL expiry will as well be
delay variation is outside the scope of this document. looped back. The use of data packets to measure packet loss, delay
and delay variation is outside the scope of this document.
6. Operation 6. Operation
6.1. General Procedures 6.1. General Procedures
When placing an LSP into Loopback mode, the operation MUST first be When placing an LSP into Loopback mode, the operation MUST first be
preceded by a Lock operation. preceded by a Lock operation.
Sending LSP Ping Echo Request message with Loopback Request/Removal When sending Loopback Request/Removal using LSP Ping or in-Band
or in-Band Loopback Request/Removal Message messages the TTL of the topmost label is set as follows:-
The TTL of the topmost label is set as follows:-
If the target node is a MIP, the TTL MUST be set to the exact number If the target node is a MIP, the TTL MUST be set to the exact number
of hops required to reach that MIP. of hops required to reach that MIP.
If the target node is a MEP, the value MUST be set to at least the If the target node is a MEP, the value MUST be set to at least the
number of hops required to reach that MEP. For most operations where number of hops required to reach that MEP. For most operations where
the target is a MEP, the TTL MAY be set to 255. the target is a MEP, the TTL MAY be set to 255.
However, to remove a MEP from Loopback mode, the sending MEP MUST set However, to remove a MEP from Loopback mode, the sending MEP MUST set
the TTL to the exact number of hops required to reach the MEP (if the the TTL to the exact number of hops required to reach the MEP (if the
TTL were set higher, the Loopback removal message would be looped TTL were set higher, the Loopback removal message would be looped
back toward the sender). It is RECOMMENDED that the TTL be set to the back toward the sender).
exact number of hops required to reach the MEP.
6.2. Example Topology 6.2. Example Topology
The next four sections discuss the procedures for Locking, Unlocking, The next four sections discuss the procedures for Locking, Unlocking,
setting an LSP into loopback, and removing the loopback. The setting an LSP into loopback, and removing the loopback. The
description is worded using an example. Assume an LSP traverses nodes description is worded using an example. Assume an LSP traverses nodes
A <--> B <--> C <--> D. We will refer to the Maintenance Entities A <--> B <--> C <--> D. We will refer to the Maintenance Entities
involved as MEP-A, MIP-B, MIP-C, and MEP-D respectively. Suppose a involved as MEP-A, MIP-B, MIP-C, and MEP-D respectively. Suppose a
maintenance operation invoked at node A requires a loopback be set at maintenance operation invoked at MEP-A requires a loopback be set at
node C. To invoke Loopack mode at node C, A would first need to lock MIP-C. To invoke Loopack mode at MIP-C, A would first need to lock
the LSP. Then it may proceed to set the loopback at C. Following the the LSP. Then it may proceed to set the loopback at C. Following the
loopback operation, A would need to remove the loopback at C and loopback operation, A would need to remove the loopback at C and
finally unlock the LSP. finally unlock the LSP.
The following sections describe MEP-A setting and unsetting a lock at The following sections describe MEP-A setting and unsetting a lock at
MEP-D and then setting and removing a loopback at MIP-C. MEP-D and then setting and removing a loopback at MIP-C.
6.3. Locking an LSP 6.3. Locking an LSP
1. MEP-A sends an MPLS LSP Ping Echo request message with the Lock 1. MEP-A sends an MPLS LSP Ping Echo request message with the Lock
TLV or an in-Band Lock request Message. Optionally, an authentication TLV or an in-Band Lock request Message. Optionally, an authentication
TLV MAY be included. TLV MAY be included.
2. Upon receiving the request message, D uses the received label 2. Upon receiving the request message, D uses the received label
stack and the Target FEC/source MEP-ID to identify the LSP. If no stack and the Target Stack FEC TLV as per [5]/source MEP-ID to
label binding exists or there is no associated LSP back to the identify the LSP. If no label binding exists or there is no
originator, the event is logged. Processing ceases. Otherwise the associated LSP back to the originator, the event is logged.
message is delivered to the target MEP. 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 a. if the source MEP-ID does not match, the event is logged and
processing ceases. processing ceases.
b. if the target MEP-ID does not match, MEP-D sends a response with b. if the target MEP-ID does not match, MEP-D sends a failure
error code 1. response with cause code 1.
MEP-D then examines the message, and: MEP-D then examines the message, and:
c. if the message is malformed, it sends a response with error code 2 c. if the message is malformed, it sends a failure response with
back to MEP-A. cause code 2 back to MEP-A.
d. if message authentication fails, it MAY send a response with error d. if message authentication fails, it MAY send a failure response
code 4 back to MEP-A. with cause code 4 back to MEP-A.
e. if any of the TLVs is not known, it sends a response with error e. if any of the TLVs is not known, it sends a failure response with
code 3 back to MEP-A. It may also include the unknown TLVs. cause code 3 back to MEP-A. It may also include the unknown TLVs.
f. if the LSP is already locked, it sends a response with f. if the LSP is already locked, it sends a response with
error code 5 back to MEP-A. cause code 5 back to MEP-A.
g. if the LSP is not already locked and cannot be locked, it sends a g. if the LSP is not already locked and cannot be locked, it sends a
response with error code 7 back to A. failure response with cause code 7 back to A.
h. if the LSP is successfully locked, it sends a response with error h. if the LSP is successfully locked, it sends a success response
code 0 (Success) back to MEP-A. with cause code 0 (Success) back to MEP-A.
The response is sent using an MPLS LSP Ping echo reply with a The response is sent using an MPLS LSP Ping echo reply with a
response TLV or an in-Band Lock response message. An authentication response TLV or an in-Band Lock response message. An authentication
TLV MAY be included. TLV MAY be included.
MEP-D will lock the LSP, resulting in that all traffic from D to A,
including all OAM traffic, stops.
a. MEP-A will detect a discontinuation in the OAM traffic, e.g. cv
and cc packets, but since it has been informed that the LSP will
be locked it will take no action(s).
b. When MEP-A receives the LI ACK, MEP-A discontinues sending
other OAM traffic, e.g. cv and cc packets. MEP-D will detect
this, but since it is in Locked state it will take no action.
6.4. Unlocking an LSP 6.4. Unlocking an LSP
1. MEP-A sends an MPLS Echo request message with the unLock TLV or an 1. MEP-A sends an MPLS Echo request message with the unLock TLV or an
in-Band unLock request Message. Optionally, an authentication TLV MAY in-Band unLock request Message. Optionally, an authentication TLV MAY
be included. be included.
2. Upon receiving the unLock request message, D uses the received 2. Upon receiving the unLock request message, D uses the received
label stack and target FEC/source MEP-ID to identify the LSP. If no label stack and target FEC/source MEP-ID as per [5] to identify the
label binding exists or there is no associated LSP back to the LSP. If no label binding exists or there is no associated LSP back to
originator, the event is logged. Processing ceases. Otherwise the the originator, the event is logged. Processing ceases. Otherwise the
message is delivered to the target MEP. message is delivered to the target MEP.
a. if the source MEP-ID does not match, the event is logged and a. if the source MEP-ID does not match, the event is logged and
processing ceases. processing ceases.
b. if the target MEP-ID does not match, MEP-D sends a response with b. if the target MEP-ID does not match, MEP-D sends a failure
error code 1. response with cause code 1.
MEP-D then examines the message, and: MEP-D then examines the message, and:
c. if the message is malformed, it sends a response with error code 2 c. if the message is malformed, it sends a failure response with
back to MEP-A. cause code 2 back to MEP-A.
d. if message authentication fails, it MAY send a response with error d. if message authentication fails, it MAY send a failure response
code 4 back to MEP-A. with cause code 4 back to MEP-A.
e. if any of the TLVs is not known, it sends a response with error e. if any of the TLVs is not known, it sends a failure response with
code 3 back to MEP-A. It may also include the unknown TLVs. cause code 3 back to MEP-A. It may also include the unknown TLVs.
f. if the LSP is already unlocked, it sends a response with f. if the LSP is already unlocked, it sends a response with
error code 6 back to MEP-A. cause code 6 back to MEP-A.
g. if the LSP is locked and cannot be unlocked, it sends a response g. if the LSP is locked and cannot be unlocked, it sends a response
with error code 8 back to MEP-A. with cause code 8 back to MEP-A.
h. if the LSP is successfully unlocked, it sends a response with h. if the LSP is successfully unlocked, it sends a success response
error code 0 (Success) back to MEP-A. with cause code 0 (Success) back to MEP-A.
The response is sent using an MPLS LSP Ping echo reply with a The response is sent using an MPLS LSP Ping echo reply with a
response TLV or an in-Band unlock response message. An authentication response TLV or an in-Band unlock response message. An authentication
TLV MAY be included. TLV MAY be included.
6.5. Interoperability with Lock Instruct OAM function 6.5. Setting an LSP into Loopback mode
a. Upon receiving a lock instruct MEP-D will lock the LSP,
resulting in that all traffic from D to A, including OAM, stops.
b. MEP-A will detect a discontinuation in the OAM traffic, e.g. cv
and cc, but since it has been informed that the LSP will be
locked it will take no action(s).
c. MEP-D will send an LI Ack, and be prepared that all traffic,
including OAM will stop
d. When MEP-A receives the LI ACK, MEP-A discontinues sending OAM
traffic.
e. MEP-D will detect this, but since it is in Locked state it will
take no action.
6.6. Setting an LSP into Loopback mode
1. MEP-A sends an MPLS LSP Ping Echo request message with the 1. MEP-A sends an MPLS LSP Ping Echo request message with the
loopback TLV or an in-Band Loopback request message. Optionally, an loopback TLV or an in-Band Loopback request message. Optionally, an
authentication TLV MAY be included. authentication TLV MAY be included.
2. Upon intercepting the MPLS Loopback message via TTL expiration, C 2. Upon intercepting the MPLS Loopback message via TTL expiration, C
uses the received label stack and target FEC/source MEP-ID to uses the received label stack and target FEC/source MEP-ID as per [5]
identify the LSP. to identify the LSP.
If no label binding exists or there is no associated LSP back to the If no label binding exists or there is no associated LSP back to the
originator, the event is logged. Processing ceases. originator, the event is logged. Processing ceases.
Otherwise the message is delivered to the target MIP/MEP - in this Otherwise the message is delivered to the target MIP/MEP - in this
case MIP-C. case MIP-C.
a. if the source MEP-ID does not match, the event is logged and a. if the source MEP-ID does not match, the event is logged and
processing ceases. processing ceases.
b. if the target MIP-ID does not match, MIP-C sends a response with b. if the target MIP-ID does not match, MIP-C sends a failure
error code 1. response with cause code 1.
MIP-C then examines the message, and: MIP-C then examines the message, and:
c. if the message is malformed, it sends a response with error code 2 c. if the message is malformed, it sends a failure response with
back to MEP-A. cause code 2 back to MEP-A.
d. if the message authentication fails, it sends a response with d. if the message authentication fails, it sends a failure response
error code 4 back to MEP-A. with cause code 4 back to MEP-A.
e. if any of the TLV is not known, C sends a response with error code e. if any of the TLV is not known, C sends a failure response with
3 back to MEP-A. It may also include the unknown TLVs. cause code 3 back to MEP-A. It may also include the unknown TLVs.
f. if the LSP is already in the requested loopback mode, it sends a f. if the LSP is already in the requested loopback mode, it sends a
response with error code 9 back to MEP-A. failure response with cause code 9 back to MEP-A.
g. if the LSP is not already in the requested loopback mode and that g. if the LSP is not already in the requested loopback mode and that
loopback mode cannot be set, it sends a response with error code 11 loopback mode cannot be set, it sends a failure response with cause
back to MEP-A. code 11 back to MEP-A.
h. if the LSP is successfully programmed into the requested loopback h. if the LSP is successfully programmed into the requested loopback
mode, it sends a response with error code 0 (Success) back to MEP-A. mode, it sends a success response with cause code 0 (Success) back to
MEP-A.
The response is sent using an MPLS LSP Ping echo reply with a The response is sent using an MPLS LSP Ping echo reply with a
response TLV or an in-Band Loopback response message. An response TLV or an in-Band Loopback response message. An
authentication TLV MAY be included. authentication TLV MAY be included.
6.7. Removing an LSP from Loopback mode 6.6. Removing an LSP from Loopback mode
1. MEP-A sends a MPLS LSP Ping Echo request message with the Loopback 1. MEP-A sends a MPLS LSP Ping Echo request message with the Loopback
removal TLV or an in-Band Loopback removal request message. removal TLV or an in-Band Loopback removal request message.
Optionally, an authentication TLV MAY be included. Optionally, an authentication TLV MAY be included.
2. Upon intercepting the MPLS Loopback removal message via TTL 2. Upon intercepting the MPLS Loopback removal message via TTL
expiration, C uses the received label stack and the target FEC/source expiration, C uses the received label stack and the target FEC/source
MEP-ID to identify the LSP. MEP-ID as per [5] to identify the LSP.
If no label binding exists or there is no associated LSP back to If no label binding exists or there is no associated LSP back to
the originator, the event is logged. Processing ceases. the originator, the event is logged. Processing ceases.
Otherwise the message is delivered to the target MIP/MEP - in this Otherwise the message is delivered to the target MIP/MEP - in this
case MIP-C. case MIP-C.
a. if the source MEP-ID does not match, the event is logged and a. if the source MEP-ID does not match, the event is logged and
processing ceases. processing ceases.
b. if the target MIP-ID does not match, MIP-C sends a response with b. if the target MIP-ID does not match, MIP-C sends a failure
error code 1 back to MEP-A. response with cause code 1 back to MEP-A.
MIP-C then examines the message, and: MIP-C then examines the message, and:
c. if the message is malformed, it sends a response with error code 2 c. if the message is malformed, it sends a failure response with
back to MEP-A. cause code 2 back to MEP-A.
d. if the message authentication fails, it sends a response with d. if the message authentication fails, it sends a failure response
error code 4 back to MEP-A. with cause code 4 back to MEP-A.
e. if any of the TLV is not known, C sends a response with error code e. if any of the TLV is not known, C sends a failure response with
3 back to MEP-A. It may also include the unknown TLVs. cause code 3 back to MEP-A. It may also include the unknown TLVs.
f. if the LSP is not in loopback mode, it sends a response with error f. if the LSP is not in loopback mode, it sends a failure response
code 10 back to MEP-A. with cause code 10 back to MEP-A.
g. if the LSP loopback cannot be removed, it sends a response with g. if the LSP loopback cannot be removed, it sends a failure response
error code 12 back to MEP-A. with cause code 12 back to MEP-A.
h. if the LSP is successfully changed from loopback mode to normal h. if the LSP is successfully changed from loopback mode to normal
mode of operation, it sends a reply with error code 0 (Success ) back mode of operation, it sends a reply with cause code 0 (Success ) back
to MEP-A. to MEP-A.
The response is sent using an MPLS LSP Ping echo reply with a The response is sent using an MPLS LSP Ping echo reply with a
response TLV or an in-Band Loopback removal response message. An response TLV or an in-Band Loopback removal response message. An
authentication TLV MAY be included. authentication TLV MAY be included.
7. Security Considerations 7. Security Considerations
The security considerations for the authentication TLV need further Security is addressed through the use of authentication TLV and the
study. the Challenge-Handshake Authentication protocol procedures described
in section [9].
8. IANA Considerations 8. IANA Considerations
8.1. Pseudowire Associated Channel Type 8.1. Pseudowire Associated Channel Type
LI-LB OAM requires a unique Associated Channel Type which is assigned LI-LB OAM requires a unique Associated Channel Type which is assigned
by IANA from the Pseudowire Associated Channel Types Registry. by IANA from the Pseudowire Associated Channel Types Registry.
Registry: Registry:
Value Description TLV Follows Reference Value Description TLV Follows Reference
----------- ----------------------- ----------- --------- ----------- ----------------------- ----------- ---------
0xHHHH LI-LB No (Section 3.1) 0xHHHH LI-LB No (Section 3.1)
8.2. New LSP Ping TLV types 8.2. New LSP Ping TLV types
IANA is requested to assign TLV type values to the following TLVs IANA is requested to assign TLV type values to the following TLVs
from the "Multiprotocol Label Switching Architecture (MPLS) Label from the "Multiprotocol Label Switching Architecture (MPLS) Label
Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub- Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-
TLVs" sub-registry. TLVs" sub-registry.
1. Lock Request TLV (See section 3.3.1) 1. LI-LB Request TLV (See section 3.3.1)
2. Unlock Request TLV (See section 3.3.2) 2. LI-LB Response TLV (See section 3.3.2)
3. Loopback Request TLV (See section 3.3.3) 3. Authentication TLV (See section 3.3.3)
4. Loopback Removal TLV (See section 3.3.4)
5. Response TLV (See section 3.3.5)
6. Authentication TLV (See section 3.3.6)
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Loa Andersson for his valuable The authors would like to thank Loa Andersson for his valuable
comments. comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
skipping to change at page 17, line 35 skipping to change at page 17, line 9
Operations, Administration, and Maintenance (OAM) in MPLS Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010. Transport Networks", RFC 5860, May 2010.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label [4] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[5] N. Bahadur, et. al., "MPLS on-demand Connectivity Verification, [5] N. Bahadur, et. al., "MPLS on-demand Connectivity Verification,
Route Tracing and Adjacency Verification", draft-nitinb-mpls- Route Tracing and Adjacency Verification", draft-ietf-mpls-tp-
tp-on-demand-cv-00, work in progress, June 2010 on-demand-cv-00, work in progress, June 2010
[6] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [6] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[7] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-ietf- [7] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-ietf-
mpls-tp-identifiers-01 (work in progress), June 2010. mpls-tp-identifiers-01 (work in progress), June 2010.
[8] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and [8] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
S.Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, S.Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
September 2009. September 2009.
[9] B. Lloyd, L&A, and W. Simpson, "PPP Authentication Protocols",
October 1992.
10.2. Informative References 10.2. Informative References
[9] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire [10] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire
Emulation Edge-to-Edge (PWE3) ", RFC5254, October 2008. Emulation Edge-to-Edge (PWE3) ", RFC5254, October 2008.
Author's Addresses Author's Addresses
Sami Boutros Sami Boutros
Cisco Systems, Inc. Cisco Systems, Inc.
Email: sboutros@cisco.com Email: sboutros@cisco.com
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 18, line 43 skipping to change at page 18, line 20
Email: dward@juniper.net Email: dward@juniper.net
Stewart Bryant Stewart Bryant
Cisco Systems, Inc. Cisco Systems, Inc.
Email: stbryant@cisco.com Email: stbryant@cisco.com
Carlos Pignataro Carlos Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
Email: cpignata@cisco.com Email: cpignata@cisco.com
Eric Osborne
Cisco Systems, Inc.
Email: eosborne@cisco.com
Nabil Bitar Nabil Bitar
Verizon. Verizon.
Email: nabil.bitar@verizon.com Email: nabil.bitar@verizon.com
Italo Busi Italo Busi
Alcatel-Lucent. Alcatel-Lucent.
Email: italo.busi@alcatel-lucent.it Email: italo.busi@alcatel-lucent.it
Lieven Levrau Lieven Levrau
Alcatel-Lucent. Alcatel-Lucent.
Email: llevrau@alcatel-lucent.com Email: llevrau@alcatel-lucent.com
Laurent Ciavaglia Laurent Ciavaglia
Alcatel-Lucent. Alcatel-Lucent.
 End of changes. 91 change blocks. 
277 lines changed or deleted 268 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/