Network Working Group Sami Boutros (Ed.)
Internet Draft Siva Sivabalan
Intended status: Standards Track George Swallow
Expires: July 2009 David Ward
Stewart Bryant
Cisco Systems, Inc.
January 9, 2009
Connection verification for MPLS Transport Profile LSP
draft-boutros-mpls-tp-cv-00.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
This Internet-Draft will expire on July 9, 2009.
Abstract
This document specifies method for verifying the connection of an
MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) for
management purpose. The proposed extension is based on MPLS
Operation, Administration, and Maintenance (OAM). The goal is to
verify that an MPLS-TP is properly setup in both control and data
Boutros Expires June 9, 2009 [Page 1]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
planes, as well as to record the identities of all the LSRs along the
path of MPLS-TP LSP.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................5
3. MPLS-TP Connection Verification Mechanism......................5
4. MPLS-OAM Connection Verification Message.......................6
4.1. Connection Verification Request TLV.......................7
4.2. Connection Verification Reply TLV.........................8
4.3. Record Route TLV..........................................8
4.4. Added returned code to the Response TLV defined in [5]....9
4.5. Network Management System.................................9
5. Operation......................................................9
6. Security Considerations.......................................11
7. IANA Considerations...........................................11
TBD..............................................................11
8. References....................................................11
8.1. Normative References.....................................11
8.2. Informative References...................................11
Author's Addresses...............................................12
Full Copyright Statement.........................................12
Intellectual Property Statement..................................13
1. Introduction
In traditional transport networks, circuits are provisioned on
multiple switches. Service Providers (SP) need to verify that the
circuits are provisioned correctly in both control and data plane for
management purpose. MPLS-TP bidirectional LSPs emulating traditional
transport circuits need to provide the same connection verification
capability.
In this document, an MPLS-TP LSP means either MPLS transport LSP or
MPLS Pseudowire (PW) [2].
The proposed solution is based on new type of MPLS-OAM message called
Connection Verification (CV) message.
An MPLS-OAM CV message originates at a Maintenance End Point (MEP)
but can be directed to by any Maintenance Intermediate Point (MIP)
along the path of MPLS-TP LSP as well as the other MEP. Therefore,
the proposed mechanism addresses the verification of the full or
partial path of an MPLS-TP LSP.
Boutros Expires June 9, 2009 [Page 2]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
An MPLS-OAM CV message is intercepted at any MIP based on MPLS TTL
expiry, and at MEP simply because it is the end of the LSP (i.e.,
regardless the value of the TTL).
In response to the MPLS-OAM CV request, each LSR along the path of
the MPLS-TP LSP appends its ID using a newly defined TLV called
Record Route TLV.
A Record Route TLV appended by a given LSR contains:
. The LSR address.
. Local Labels allocated by the LSR for both directions of the
MPLS-TP LSP.
To describe the connection verification functionality, let us assume
an MPLS-TP LSP between LSR-1 and LSR-5 passing through LSR-2, LSR-3,
and LSR-4. Thus, LSR-1 and LSR-5 are MEPs whereas LSR-2, LSR-3, and
LSR-4 are MIPs. The objective is to verify (both in control and data
planes) the MPLS-TP LSP from LSR-1 to LSR-5 (end-to-end), and record
all the IDs of the LSRs along the path. This could be accomplished
using a conventional traceroute operation in which LSR-1 interrogates
each LSR-2 through LSR-5 (using appropriate TTL value) in turn using
a new message and response, and compiles the result. This approach
requires 8 messages; a request and a response between LSR-1 and each
of the other LSRs. On the other hand, the mechanism that we describe
below can accomplish the goal with only 5 messages. The same
mechanism can work if the MPLS-TP LSP is a Multisegment PseudoWire
(MS-PW) [8].
It is possible that the path of an MPLS-TP LSP contains loop(s) due
to misconfiguration. Such mistakes are possible with manual
configuration. For example, assume that MPLS-TP LSP under discussion
is misconfigured such LSR-4 connects to LSR-2 instead of LSR-5. This
results in a loop. In this case, the MPLS-OAM CV packets self limit
when the MTU is reached, and when it happens, it is good practice to
silently drop those packets.
If a MIP does not understand the MPLS-OAM CV message, it must
silently drop the packet. To trap this condition as well as to trap
the looping condition, an ingress MEP that initiates connection
verification starts a timer when it sends an MPLS-OAM CV message. If
the timer expires before it has received a response, the MEP assumes
one of the following conditions:
. the MPLS-TP LSP is incomplete.
Boutros Expires June 9, 2009 [Page 3]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
. an LSR (either MIP or MEP) does not understand the MPLS-OAM CV
message.
. there is a loop.
The ingress MEP then examines the MPLS-TP LSP by using the classic
one-hop at a time, direct response traceroute.
In case not all hops on the path of the MPLS-TP LSP are MIPs, an
ingress MEP can send conventional trace route with incrementing TTL
1, 2, 3, ...., to all MIPs and to the egress MEP along the path. Some
of those requests will be sent to non MIP/MEP LSRs and will be
dropped silently. When the MIPs and egress MEP receive the request,
they will respond with an MPLS-OAM CV response message. The TTL value
of the response SHOULD be large to ensure the response message
reaches the ingress MEP without being intercepted at any MIP.
Optionally, the TTL value of the response MAY be set to 1 so that
each MIP can verify its ID included in the response message as the
response travels towards the ingress MEP.
An MPLS-OAM CV message contains the following information:
1. Connection ID for the MPLS-TP in question.
2. IDs of the LSR (to record the route).
3. Sequence Number to correlate a given reply with the correct
request.
The above information is carried in TLV format.
The proposed mechanism is based on a set of new TLVs which can be
transported using one of the following methods:
1. Using in-band MPLS-OAM messages which are forwarded as MPLS
packets (Non-IP-Based).
2. Using in-band LSP-Ping extensions defined in [3] where IP/UDP
packets are used (IP-Based). The LSP-Ping messages are sent
using the codepoint defined in [4].
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
Boutros Expires June 9, 2009 [Page 4]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
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.
2. Terminology
ACH: Associated Channel Header
GAL: Generalized Alert Label
LSR: Label Switching Router
MEP: Maintenance End Point
MIP: Maintenance Intermediate Point
MPLS-OAM: MPLS Operations, Administration and Maintenance
MPLS-TP: MPLS Transport Profile
MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit
MS-PW: Mult-Segment PseudoWire
NMS: Network Management System
PW: PseudoWire
RR: Record Route
TLV: Type Length Value
TTL: Time To Live
3. MPLS-TP Connection Verification Mechanism
For the Non-IP-Based option, the proposed mechanism uses a new code
point in the Associated Channel Header (ACH) described in [7].
The IP-Based option will be in compliance to specifications [3] and
[4].
Also, the proposed mechanism requires a set of new TLVs called
Connection Verification Request TLV, Connection Verification Reply
TLV, Record Route TLV. Also, Response TLVs defined in [5], and the
Boutros Expires June 9, 2009 [Page 5]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
Address Block and Connection-ID TLVs defined in [6] are also required
for this mechanism.
The new TLVs are described below.
4. MPLS-OAM Connection Verification Message
In the Non-IP-Based option, under MPLS label stack of the MPLS-TP
LSP, the ACH with "MPLS-TP Connection Verification" code point
indicates that the message is an MPLS OAM Connection Verification
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| (MPLS-TP CV code point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MPLS-TP OAM Message Header
First nibble = 0001b.
The version and the reserved values are both set to 0 as specified in
[1].
MPLS-TP Connection Verification code point (value TBD).
The Message ID is set by the sender. The receiver MUST include the
Message ID in the response. This way, the sender can correlate a
reply with the corresponding request.
The Message Length is the total length of the message in bytes
excluding the length of the MPLS-TP OAM message header.
Boutros Expires June 9, 2009 [Page 6]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
4.1. Connection Verification 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 = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ LSR Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Connection-ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Connection Verification Request TLV is used to instruct a MEP or a
MIP to record the route by appending the Record Route TLV (described
below) to the MPLS-OAM message and forward the packet along the path
of the MPLS-TP LSP (in the case of a MIP) or send a response back to
the sender MEP (in the case of the receiver MEP).
The request will contain LSR-Address and connection-ID sub-TLVs
defined in [6].
In case of errors, the receiver MEP or MIP MUST send a NAK response
to the sender MEP using an MPLS-OAM message with a Response TLV
containing the error code described below.
Boutros Expires June 9, 2009 [Page 7]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
4.2. Connection Verification Reply 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 = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ LSR Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Connection-ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Connection Verification Reply TLV is sent by a MEP or a MIP in
response to a request. The reply contains the sequence number of the
request and the LSR Address of the MEP or MIP and connection-ID Sub-
TLVs defined in [6] of the MPLS-TP LSP.
Connection verification reply is used to send all the record route
TLVs in the connection verification request to the sender MEP.
4.3. Record Route 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 = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward Local Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Local Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ LSR Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Record Route TLV includes the LSR address sub-TLV defined in [6]
as well as the forward and reverse local labels (allocated by the LSR
for both directions of the LSP). The forward local label is the label
allocated by the LSR in the direction of the connection verification
request message. The reverse local label at a MEP MUST be 0.
Boutros Expires June 9, 2009 [Page 8]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
4.4. Added returned code to the Response TLV defined in [5]
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 = 0x1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ReturnCode |
+-+-+-+-+-+-+-+
Return code
Value Meaning
----- -------
16 LSP is not setup in control or data planes
17 LSR ID not in the MPLS-OAM CV response message
Note that the proposed connection verification mechanism also
requires the some other return codes specified in [5].
4.5. Network Management System
An operator should be able to provision any given LSR to send MPLS-
OAM CV Request packets from a MEP and notify NMS when MPLS-OAM CV
Response arrives.
5. Operation
Consider an MPLS-TP LSP LSR-1 <--> LSR-2 <--> LSR-3 <--> LSR-4 <-->
LSR-5. LSR-1 and LSR-5 are ingress and egress LSR for the respective
direction. LSR-1 and LSR-5 are MEPs, and LSR-2 through LSR-4 are
MIPs.
The proposed mechanism operates as follows:
1. After the MPLS-TP LSP is configured at LSR-1 and LSR-5 with the
same connection-ID, LSR-1 sends an MPLS-OAM CV Request message
along the path of the LSP.
2. The MPLS-OAM CV Request message is intercepted at LSR-2 (MIP)
because of TTL expiry. LSR-2 then verifies the request and:
1. if the message is malformed, it sends a response with the
error code 2 back to LSR-1.
Boutros Expires June 9, 2009 [Page 9]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
2. if any of the TLV is not known, it sends a response with error
code 3 back to LSR-1. It may also include the unknown TLVs.
3. if message authentication fails, it sends a response with the
error code 4 back to LSR-1.
4. if connection-ID cannot be matched, it sends a response with
error code 14.
5. if the MPLS-TP LSP is not setup in control or data planes, it
sends a response with error code 16.
Note that MPLS TTL value is set to 255 in the response message.
3. LSR-2 then verifies the request and if connection-ID matches that
in the message, and if the MPLS-TP LSP is setup in control and data
planes, it appends its address as well as the local labels to the
message and forward it to LSR-3 with a TTL = 1.
4. LSR-3 repeats the steps (2) or (3). In the absence of error, the
messages progresses towards LSR-5 with each LSR adding its own ID
and the local labels.
5. Upon getting the MPLS-OAM CV message, LSR-5 verifies the request,
and if an MPLS-TP LSP whose connection-ID matches that in the
message is found, and if that MPLS-TP LSP is setup in both control
and data planes, LSR-5 sends a response back to the LSR-1. The
response contains the record route received by LSR-5. The TTL value
of the response will be such that the response message reaches LSR-
1 without further interception at any other LSR. As an optional
alternative, LSR-5 may send the packet down the return path with a
TTL=1 so that an LSR can verify its ID included in the response.
6. When LSR-1 receives a response with a large TTL (i.e., TTL value is
not equal to 1), it becomes aware of the IDs of each LSR on the
path as well as how far away (in terms of hop-count) is each LSR
from itself. Hence, LSR-1 may send an MPLS-OAM message directly to
any LSR using an appropriate TTL value in the future. On the other
hand, if LSR-1 receives a response with TTL value equals 1, it gets
a confirmation that the path is bidirectionally symmetric, which is
a critical consideration in transport networks.
Boutros Expires June 9, 2009 [Page 10]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
6. Security Considerations
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.
[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.
[5] S. Boutros, et. al., "Operating MPLS Transport Profile LSP in
Loopback Mode ", draft-boutros-mpls-tp-loopback-01.txt, Work in
Progress, December 2008.
8.2. Informative References
[6] S. Boutros, et. al., "Definition of ACH TLV Structure", draft-
bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009.
[7] M. Bocci, et. al., "MPLS Generic Associated Channel", draft-
ietf-mpls-tp-gach-gal-01.txt, work in progress, January 6,
2009.
[8] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire
Emulation Edge-to-Edge (PWE3)", RFC5254, October 2008.
Boutros Expires June 9, 2009 [Page 11]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
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
Stewart Bryant
Cisco Systems, Inc.
250, Longwater, Green Park,
Reading RG2 6GB, UK
UK
Email: stbryant@cisco.com
Full Copyright Statement
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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Boutros Expires June 9, 2009 [Page 12]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
carefully, as they describe your rights and restrictions with respect
to this document.
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
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.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
Boutros Expires June 9, 2009 [Page 13]
Internet-Draft draft-boutros-mpls-tp-cv-00.txt January 2009
For the avoidance of doubt, each Contributor to the UETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Boutros Expires June 9, 2009 [Page 14]