Network Working Group Sami Boutros (Ed.)
Internet Draft Siva Sivabalan
Intended status: Standards Track George Swallow
Expires: April 2009 David Ward
Cisco Systems, Inc.
October 10, 2008
Operating MPLS Transport Profile LSP in Loopback Mode
draft-boutros-mpls-tp-loopback-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 10, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Boutros Expires April 10, 2009 [Page 1]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
Abstract
This document specifies an extension to MPLS Operation,
Administration, and Maintenance (OAM) using which an MPLS Label
Switching Router (LSR) can explicitly request another MPLS LSR to
operate an MPLS Transport Profile(MPLS-TP) Label Switched Path
between the two LSRs in loopback mode. This extension can be used to
loop the data traffic up to certain LSR in the path of the MPLS LSP
back to the source for management purpose.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................4
3. MPLS-TP Loopback Mechanism.....................................4
4. MPLS-OAM Loopback Message......................................4
4.1. Lock Request TLV..........................................5
4.2. Unlock Request TLV........................................5
4.3. Loopback Request TLV......................................6
4.4. Loopback Removal TLV......................................6
4.5. Authentication TLV........................................7
4.6. Source Identifier TLV.....................................7
4.7. Response TLV..............................................8
4.8. Data packets..............................................9
5. Operation......................................................9
6. Security Considerations.......................................12
7. IANA Considerations...........................................12
TBD..............................................................12
8. References....................................................12
8.1. Normative References.....................................12
Author's Addresses...............................................13
Intellectual Property Statement..................................13
Disclaimer of Validity...........................................14
1. Introduction
In traditional transport networks, circuits are provisioned on
multiple switches and service providers operate the transport circuit
such as T1 line in loopback mode for management purpose, e.g., to
test connectivity of the circuit up to a specific switch on the path
of the circuit, to test the circuit performance with respect to
delay/jitter, etc. MPLS-TP bidirectional LSP emulating traditional
transport circuits need to provide the same loopback capability. In
this document, an MPLS-TP LSP means either MPLS transport LSP or MPLS
Pseudowires (PW).
Boutros Expires June 10, 2009 [Page 2]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
To decribe the loopback functionality, let us assume a bidirectional
MPLS-TP LSP A <---> B <---> C where A, B, and C are MPLS capable
nodes. Furthermore, let us assume that A wants B to loop the data
packet sent from A back to B. In this example, A and C acts as
Maintenance End Points (MEPs) and B acts as a Maintenance
Intermediate Point (MIP).
First, A sends an in-band MPLS OAM packet along the MPLS-TP LSP to
lock the circuit. The message will be intercepted by C since it is at
the end of the LSP. When C responds with an ACK to the lock request,
A sends another in-band message with the correct MPLS TTL value on
the OAM packet so that the MPLS OAM packet will be intercepted by B
because of the MPLS TTL expiry. The second MPLS OAM packet contains a
request to instruct B to operate the corresponding MPLS-TP LSP in
loopback mode.
B sends an ACK/NAK OAM reply message back to A to indicate whether or
not the corresponding MPLS-TP LSP has been programmed into loopback
mode. In the case of NAK, the OAM reply message contains an error
code. Moreover, upon receiving a NAK reply to the loopback request, A
sends another MPLS OAM message to unlock the LSP. The unlock message
is intercepted by C as it is at the end of the LSP.
When the MPLS-TP LSP operates in a loopback mode, data packets from A
to B sent over that LSP are looped back to A. When loopback mode
operation is no longer required, A sends another MPLS OAM message to
remove the loopback mode operation, and the MPLS TTL is set such that
this message is intercepted by B. It is expected that B sends a reply
back to A to ACK/NAK the loopback mode removal request. Upon getting
an ACK response to loopback mode removal request, A sends another
MPLS OAM message to unlock the LSP, and this message is intercepted
by C as it is at the end of the LSP.
In the following sections, we describe proposed new MPLS OAM messages
and the TLVs in detail.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 Error!
Reference source not found.
Boutros Expires June 10, 2009 [Page 3]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
2. Terminology
ACH: Associated Channel Header
LSR: Label Switching Router
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
TLV: Type Length Value
TTL: Time To Live
3. MPLS-TP Loopback Mechanism
The proposed mechanism is based on a new code point in the Associated
Channel Header (ACH) described in [1] and a few added TLVs for the
existing MPLS OAM message. These TLVs are Loopback Request TLV,
Loopback Removal TLV, Lock Request TLV, Lock Removal TLV, Source
Address TLV, Authentication Request TLV, and Response TLV.
4. MPLS-OAM Loopback Message
Under MPLS label stack of the MPLS-TP LSP, the ACH with "MPLS-TP
Looback" code point indicates that the message is an MPLS OAM
Loopback message. In addition, a 32-bit field is added to carry the
message ID and the message length as 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|0 0 0 0|0 0 0 0 0 0 0 0| 0xHH (MPLS-TP Loopback) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MPLS-TP OAM Message Header
Boutros Expires June 10, 2009 [Page 4]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
First nibble = 0001b.
The version and the reserved values are both set to 0 as specified in
[1].
MPLS-TP looback code point = 0xHH
The Message ID is set by the sender. The receiver MUST include the
Message ID in the response.
The Message Length is the total length of the message in bytes
excluding the length of the MPLS-TP OAM message header.
4.1. Lock 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 = 0x1 | length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lock Request TLV is used to request a MEP to take an MPLS-TP LSP out
of service so that some form of maintenance can be done on the MPLS-
TP. A MEP includes a Lock Request TLV in the MPLS OAM message to
request the MEP on the other side of the MPLS-TP LSP to take the
MPLS-TP LSP out of service.
The receiver MEP MUST send either an ACK or a NAK response to the
sender MEP using an MPLS OAM message with a Response TLV described
below. Until the sender MEP receives an ACK, it MUST NOT assume that
the receiver MEP has taken the MPLS-TP out of service. A receiver MEP
sends an ACK only if it can successfully lock the MPLS-TP. Otherwise,
it sends a NAK.
4.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 = 0x2 | length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unlock Request TLV is sent from the MEP which has previously sent
lock request via MPLS OAM message. Upon receiving the message, the
receiver MEP brings the MPLS-TP back in service.
Boutros Expires June 10, 2009 [Page 5]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
The receiver MEP MUST send either an ACK or a NAK response to the
sender MEP using an MPLS OAM message with a Response TLV described
below. Until the sender MEP receives an ACK, it MUST NOT assume that
the MPLS-TP LSP has been put back in service. A receiver MEP sends an
ACK only if the MPLS-TP LSP has been unlocked, and unlock operation
is successful. Otherwise, it sends a NAK.
4.3. Loopback 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 = 0x3 | length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a MEP wants to put an MPLS-TP in loopback mode, it sends a MPLS
OAM message with Loopback Request TLV. The loopback message can be
intercepted by either a MIP or a MEP depending on the MPLS TTL value.
The receiver puts in correcponding MPLS-TP LSP in loopback mode.
The receiver MEP or MIP MUST send either an ACK or NAK response to
the sender MEP using an MPLS OAM message with a Response TLV
described below. An ACK response is sent if the MPLS-TP LSP is
successfully put in loopback mode. Otherwise, a NAK response is sent.
Until an ACK response is received, the sender MEP MUST NOT assume
that the MPLS-TP LSP can operate in loopback mode.
4.4. Loopback Removal 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 = 0x4 | length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When loopback mode operation of an MPLS-TP LSP is no longer required,
the MEP that previously sent the MPLS OAM loopback message sends
another MPLS OAM message with a Loopback Removal TLV. The receiver
MEP change the MPLS-TP LSP from loopback mode to normal mode of
operation.
The receiver MEP or MIP MUST send either an ACK or NAK response to
the sender MEP using an MPLS OAM message with a Response TLV
described below. An ACK response is sent if the MPLS-TP LSP is
already in loopback mode, and if the MPLS-TP LSP is successfully put
Boutros Expires June 10, 2009 [Page 6]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
back in normal operation mode. Otherwise, a NAK response is sent.
Until an ACK response is received, the sender MEP MUST NOT assume
that the MPLS-TP LSP is put back in normal operation mode.
4.5. 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 = 0x5 | 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 OAM
loopback request message. The use of authentication key is outside
the scope of the document.
4.6. Source Identifier 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 = 0x6 (IPv4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Source Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
While setting up an MPLS-TP LSP in loopback mode, the sender MEP can
include its ID in the the Source Identifier TLV. The ID can be in
IPv4, IPv6, or PW FEC (128 or 129) formats. The length field
represents the length (in bytes) of only the source identifier.
Depending on the format, type and length are interpretted as follows:
Format Type Length
------ ---- ------
IPv4 address 0x6 4
IPv6 address 0x7 16
FEC 128 Pseudo Wire Identifier 0x8 4
FEC 129 Pseudo Wire Identifier 0x9 Variable
Boutros Expires June 10, 2009 [Page 7]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
In the case of FEC 129, the source is identified by AGI, SAII, and TAII
as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Value (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAII Value (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII Value (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For more details on AGI, SAII, and TAII, please refer to [2].
The use of the Source Identifier TLV is outside the scope of this
document.
4.7. Response 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 = 0x10 | Length = 0x1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ReturnCode |
+-+-+-+-+-+-+-+
Return code
Value Meaning
----- -------
0 No error code
1 Success
2 Malformed loopback request received
3 One or more of the TLVs is/are unknown
Boutros Expires June 10, 2009 [Page 8]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
4 Authentication failed
5 MPLS-TP LSP is locked
6 MPLS-TP LSP is not locked
7 Fail to lock MPLS-TP LSP
8 Fail to unlock MPLS-TP LSP
9 MPLS-TP LSP is 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
Note that in the case of error code 2, the unknown TLV can also be
optionally included in the response TLV.
4.8. Data packets
When an MPLS-TP LSP operates in loopback mode, data packets sent from
the sender MEP will be looped back to that sender MEP. In order for
the sender MEP to make ensure that no data packets are dropped, each
data MPLS packets MUST contain a sequence-id right after the label
stack.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label stack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label with EOS bit set |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequcence-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Operation
Assume an MPLS-TP LSP A <--> B <--> C, and A wants to request B to
set the MPLS-TP LSP in loopback mode. The following steps are carried
out:
Boutros Expires June 10, 2009 [Page 9]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
1. A sends an MPLS-OAM loopback request message consisting of an ACH
with the MPLS-TP Loopback code, Lock TLV, and optional
authentication TLV to C. The MPLS label stack of the LSP is added
and the MPLS TTL value is set to 255.
2. Upon intercepting the MPLS-OAM message, C examines the message,
and:
a. if the message is malformed, it sends a response with the
error code 2 back to A.
b. if any of the TLV is not known, it sends a response with error
code 3 back to A. It may also include the unknown TLVs.
c. if message authentication fails, it sends a response with the
error code 4 back to A.
d. if the MPLS-TP is already locked, it sends a response with
error code 5 back to A.
e. if the MPLS-TP is not already locked and cannot be locked, it
sends a response with error code 7 back to A.
f. if the MPLS-TP is successfully locked, it sends a response an
error code 1 (success) back to A.
Note that MPLS TTL value is set to 255 in the response message.
3. Upon receiving the MPLS-OAM response message with error code 1, A
sends an MPLS-OAM loopback request message consisting of an ACH
with the MPLS-TP Loopback code to B. The message can optionally
have authentication TLV, and source TLV. The MPLS label stack of
the LSP is added and the MPLS TTL value is set to the number of
hops between A and B.
4. Upon intercepting the MPLS-OAM message, B examines the message,
and:
a. if the message is malformed, it sends a response with error
code 2.
b. if any of the TLV is not known, B sends a response with error
code 3. It may also include the unknown TLVs.
c. if the message authentication fails, it sends a response with
error code 4.
Boutros Expires June 10, 2009 [Page 10]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
B identifies the MPLS bidirectional LSP:
a. if the MPLS-TP is already in loopback mode, it sends a
response with error code 9.
b. if the MPLS-TP is successfully set in loopback mode, it sends
a reply with error code 1 (success).
5. After receiving a positive reply from B, A can send data packets
on the MPLS-TP LSP to B, and expect those packets to loopback to
itself. The data packets contains sequence numbers to check for
packet loss.
6. B simply loops the data packets coming over the MPLS-TP LSP back
towards the source. The MPLS label stack of the LSP is added and
the MPLS TTL value is set to 255.
To unlock the MPLS-TP LSP:
1. A sends an MPLS-OAM loopback request message consisting of an ACH
with the MPLS-TP Loopback code, Unlock Request TLV and optionally
an authentication TLV. The MPLS label stack of the LSP is added
and the MPLS TTL value is set to 255.
2. Upon intercepting the MPLS-OAM message, C examines the message,
and:
a. if the message is malformed, it sends a response with the
error code 2 back to A.
b. if any of the TLV is not known, it sends a response with error
code 3 back to A. It may also include the unknown TLVs.
c. if message authentication fails, it sends a response with the
error code 4 back to A.
C identifies the MPLS-TP LSP:
a. if the MPLS-TP is not locked, it sends a response with error
code 6 back to A.
b. if the MPLS-TP is locked and cannot be unlocked, it sends a
response with error code 8 back to A.
c. if the MPLS-TP is successfully unlocked, it sends a response
an error code 1 (success) back to A.
Boutros Expires June 10, 2009 [Page 11]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
To remove MPLS-TP LSP from loopback mode:
1. A sends an MPLS-OAM loopback request message consisting of an ACH
with the MPLS-TP Loopback code, Loopback Removal Request TLV and
optionally an authentication TLV. The MPLS label stack of the LSP
is added and the MPLS TTL value is set to the number of hops
between A and B.
2. Upon intercepting the MPLS-OAM message, B examines the message
and:
a. if the message is malformed, it sends a response with error
code 2.
b. if any of the TLV is not known, B sends a response with error
code 3. It may also include the unknown TLVs.
c. if the message authentication fails, it sends a response with
error code 4.
B identifies the MPLS bidirectional LSP:
c. if the MPLS-TP is not in loopback mode, it sends a response
with error code 10.
d. if the MPLS-TP is successfully changed from loopback mode to
normal mode of operation, it sends a reply with error code
1(success).
6. Security Considerations
The security considerations for the authentication TLV need further
study.
7. IANA Considerations
TBD
8. References
8.1. Normative References
[1] Bradner. S, " Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997.
Boutros Expires June 10, 2009 [Page 12]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
[2] M. Bocci, et. al., "MPLS Generic Associated Channel", draft-
bocci-pwe3-mpls-tp-ge-ach-00.txt, Work in progress, June 26,
2008.
[3] L. Martini, et. al., " Pseudowire Setup and Maintenance Using
the Label Distribution Protocol (LDP)", RFC4447, April, 2006.
Author's Addresses
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: sboutros@cisco.com
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada
Email: msiva@cisco.com
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MASSACHUSETTS 01719
United States
Email: swallow@cisco.com
David Ward
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: wardd@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Boutros Expires June 10, 2009 [Page 13]
Internet-Draft draft-boutros-mpls-tp-loopback-00.txt October 2008
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users 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
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Boutros Expires June 10, 2009 [Page 14]