Network Working Group Sami Boutros (Ed.)
Internet Draft Siva Sivabalan (Ed.)
Intended status: Standards Track George Swallow (Ed.)
Expires: February 2010
Cisco Systems, Inc.
Martin Vigoureux (Ed.)
Alcatel-Lucent
A. Fulignoli (Ed.)
Ericsson
July 6, 2009
Connection Verification and Continuity Check for MPLS Transport
Profile Label Switched Path
draft-boutros-mpls-tp-cv-cc-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 February 6, 2010.
Boutros Expires February 6, 2010 [Page 1]
Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009
Abstract
Connection Verification (CV) and Continuity Check (CC) are
important Operations, Administration, and Management (OAM)functions
of MPLS Transport Profile (MPLS-TP). This document specifies
methods for CV and CC for MPLS-TP Label Switched Path (LSP) using
Bidirectional Forwarding Detection (BFD).
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. MPLS-TP Connection Verification and Continuity Check Mechanism.3
3.1. MPLS-TP CV/CC Message format..............................4
3.2. BFD Profile for MPLS-TP...................................5
4. Operation......................................................6
5. Security Considerations........................................7
6. IANA Considerations............................................7
7. References.....................................................7
7.1. Normative References......................................7
7.2. Informative References....................................7
Author's Addresses................................................8
Full Copyright Statement..........................................9
Intellectual Property Statement...................................9
1. Introduction
In traditional transport networks, circuits are provisioned on
multiple switches. Service Providers (SP) need OAM tools to detect
mis-connectivity and loss of continuity of transport circuits. MPLS-
TP LSPs [6] emulating traditional transport circuits need to provide
the same CC and CV capabilities as mentioned in [2]. This document
describes the use of BFD [3] for CV and CC of an MPLS-TP LSP between
2 Maintenance End Points (MEPs). The mechanism specified in this
document is restricted only to BFD asynchronous mode. The proposed
method uses BFD state machine defined in Section 6.2 of [3].
Moreover, this document recommends the use of BFD for the Pseudowire
Virtual Circuit Connectivity Verification (VCCV)as defined in [5].
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Boutros Expires February 6, 2010 [Page 2]
Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009
document are to be interpreted as described in RFC-2119 [1].
2. Terminology
ACH: Associated Channel Header
BFD: Bidirectional Forwarding Detection
CV: Connection Verification
EOS: End of Stack
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
RDI: Remote defect indication.
3. MPLS-TP Connection Verification and Continuity Check Mechanism
The proposed mechanism is based on a new code point in the Generic
Associated Channel Header (G-ACH) described in [8]. Under MPLS label
stack of the MPLS-TP LSP, the ACH with "MPLS-TP Connection
Boutros Expires February 6, 2010 [Page 3]
Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009
Verification/Continuity Check (CV/CC)" code point indicates that the
message is an MPLS-TP CV/CC message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Flags | 0xHH MPLS-TP CV/CC Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of MPLS-TP Connection Verification
The first nibble (0001b) indicates the ACH.
The version and the reserved values are both set to 0 as specified in
[8].
MPLS-TP CV/CC code point = 0xHH. [HH to be assigned by IANA from the
PW Associated Channel Type registry.]
3.1. MPLS-TP CV/CC Message format
The format of an MPLS-TP CV/CC Message format is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label (EOS) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| |
~ Destination and Source Node-IDs of the MPLS-TP LSP ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ BFD Control Packet ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS-TP CV/CC Message
Boutros Expires February 6, 2010 [Page 4]
Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009
As shown in Figure 2, BFD Control packet as defined in [3] is
transmitted as MPLS labeled packets along with GAL, G-ACH, and TLVs
carrying the Destination and Source Node-IDs of the MPLS-TP LSP as
defined in a new IETF draft to be published soon.
The TTL field of the GAL MUST be set to at least 1, and the GAL will
be the end of stack label.
The discriminator values in the BFD control packet will be set to the
LIH (Logical Interface Handle) at each side of the MPLS-TP LSP.
Combination of the Source/Destination Node-IDs and discriminator
value (from the BFD packet) represents MEP-ID, i.e., the combination
of the source node address and my discriminator is the Source MEP-ID,
and the combination of the destination node address and your
discriminator is the peer MEP-ID. Note that the format of Node ID is
defined in [7].
In this mode of operation, the IP/UDP headers for the BFD control
packets are omitted from the BFD encapsulation.
Furthermore, BFD is used not only for fault detection but also for
mis-insertion and for Remote Defect Indication (RDI). Reception of a
BFD control packet having an unexpected source Node-ID, destination
Node-ID or discriminator(s) is considered a BFD mis-insertion fault.
Reception of BFD control packet with a diagnostic code of 1 (Control
Detection Time Expired) or 5 (Path down) is considered an RDI fault.
3.2. BFD Profile for MPLS-TP
BFD MUST run in asynchronous mode as described in [3].
In all BFD control packets sent, both "Desired Min TX Interval" and
"Required Min RX Interval" MUST be set to the operator configured
values for BFD transmission period for the MPLS-TP LSP. If the
received BFD packets have different "Desired Min TX Interval field"
than the one used for the transmitted packets, the BFD session MUST
NOT come up by default, except if the behavior is overridden by an
operator using explicit configuration.
By default the transmission rates MUST be the same at both end of the
MPLS-TP LSP (both working and protecting).
The "my discriminator" field in the BFD control packets is set to the
MPLS-TP LSP's local LIH (Logical Interface Handle) and the "your
discriminator" field is initially set to zero. During BFD session
Boutros Expires February 6, 2010 [Page 5]
Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009
negotiation, the "my discriminator" field in the received BFD packets
MUST match the remote discriminator.
4. Operation
Single-hop BFD initialization procedures described in [4] are
followed. As mentioned before, only asynchronous mode is supported.
The operation of BFD over MPLS-TP LSP is symmetrical. Both endpoints
of the bidirectional MPLS-TP LSP MUST send BFD messages inband in the
MPLS-TP LSP using the defined code point.
Both MEPs at the end of an MPLS-TP LSP need to bootstrap the BFD
session and start sending BFD control packets encapsulated within
MPLS-TP CV/CC message described in this document. MPLS-TP LSP labels
at both ends of the MPLS-TP LSP will be used as the de-multiplexer
for the received BFD packets, and no discriminator values will be
used.
A single BFD session per MPLS-TP LSP will exist between the MEP's of
the MPLS-TP LSP. Both MEP's will be sending initial BFD Control
packets with a "Your Discriminator" field of zero, and BFD Control
packets received with a "Your Discriminator" field of zero are
associated to the BFD session bound to the MPLS-TP LSP.
Both "Desired Min TX Interval" and "Required Min RX Interval" MUST be
set to the configured BFD transmission period for the MPLS-TP LSP.
Assume an MPLS-TP LSP that spans across LSR-A, LSR-B and LSR-C. LSR-A
LSR-C act as the MEPs whereas LSR-B act as a MIP for the MPLS-TP LSP.
Furthermore, assume that on both LSR-A and LSR-C the operator
provision the BFD detection time multiplier as per [3].
If LSR-A receives a BFD control message that has a destination node
identifier different from it's identifier, or has an unexpected
source node identifier, or non-zero your discriminator value or has a
my discriminator value different from what LSR-A is expecting, LSR-A
declares that the MPLS-TP LSP is down in its receive direction. In
this case, LSR-A signals LSR-C that the BFD session is down using the
State (Sta) with diagnostic code 5 (Path down).
Boutros Expires February 6, 2010 [Page 6]
Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009
If LSR-A stops receiving BFD control messages from LSR-C for a period
of detection time multiplier (calculation of Detection Time is
defined in[3]), LSR-A declares that the MPLS-TP LSP is down in its
receive direction, and signals this to the remote end via the State
(Sta) with Diagnostic code 1(Control Detection Time Expired). In
turn, LSR-C declares the MPLS-TP LSP is down in its transmit
direction setting the State to Down with Diagnostic code 3 (Neighbor
signaled session down) in its control messages to LSR-A.
5. Security Considerations
The security considerations for the authentication TLV need further
study.
6. IANA Considerations
To be added.
7. References
7.1. Normative References
[1] Bradner. S, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997.
[2] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-
02 (work in progress), June 2009.
[3] Katz, D., and D. Ward, "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-09 (work in progress), August 2009.
[4] Katz, D., and D. Ward, "Generic Application of BFD", draft-
ietf-bfd-generic-05 (work in progress), February 2009.
[5] T. Nadeau, et. Al, Bidirectional Forwarding Detection (BFD) for
the Pseudowire Virtual Circuit Connectivity Verification
(VCCV), draft-ietf-pwe3-vccv-bfd-05, June 2009.
7.2. Informative References
[6] M. Bocci, et. al., "A Framework for MPLS in Transport
Networks", draft-ietf-mpls-tp-framework-01.txt, Work in
Progress, June 2009.
[7] S. Boutros, et. al., "Definition of ACH TLV Structure", draft-
bryant-mpls-tp-ach-tlv-01.txt, Work in Progress, May 2009.
Boutros Expires February 6, 2010 [Page 7]
Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009
[8] M. Bocci, et. al., "MPLS Generic Associated Channel", RFC 5586,
June, 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
Martin Vigoureux
Boutros Expires February 6, 2010 [Page 8]
Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009
Alcatel-Lucent
Email: martin.vigoureux@alcatel-lucent.com
Annamaria Fulignoli (Editor)
Ericsson
Email: annamaria.fulignoli@ericsson.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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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
Boutros Expires February 6, 2010 [Page 9]
Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009
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.
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 February 6, 2010 [Page 10]