draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00.txt   draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01.txt 
Network Working Group N. Bahadur, Ed. Network Working Group N. Bahadur, Ed.
Internet-Draft R. Aggarwal, Ed. Internet-Draft R. Aggarwal, Ed.
Intended status: Standards Track D. Ward, Ed. Intended status: Standards Track D. Ward, Ed.
Expires: September 24, 2010 Juniper Networks, Inc. Expires: February 23, 2011 Juniper Networks, Inc.
T. Nadeau T. Nadeau
BT BT
N. Sprecher N. Sprecher
Y. Weingarten Y. Weingarten
Nokia Siemens Networks Nokia Siemens Networks
March 23, 2010 August 22, 2010
LSP-Ping and BFD encapsulation over ACH LSP-Ping and BFD encapsulation over ACH
draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01
Abstract Abstract
LSP-Ping and BFD for MPLS are existing and widely deployment OAM LSP-Ping and BFD for MPLS are existing and widely deployment OAM
mechanisms for MPLS LSPs. This document describes ACH encapsulation mechanisms for MPLS LSPs. This document describes an ACH
for LSP-Ping, to enable use of LSP-Ping when IP addressing is not in encapsulation for LSP-Ping, that would enable use of LSP-Ping for
use. This document also clarifies the use of BFD for MPLS LSPs using networks where IP addressing is not in use. This document also
ACH encapsulation, when IP addressing may not be available and/or it clarifies the use of BFD for MPLS LSPs using ACH encapsulation, when
may not be desirable to encapsulate BFD packets in IP. IP addressing may not be available and/or it may not be desirable to
encapsulate BFD packets in IP.
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 47 skipping to change at page 1, line 48
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 24, 2010. This Internet-Draft will expire on February 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 26 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3
1.2. LSP-Ping and BFD over ACH . . . . . . . . . . . . . . . . . 3 1.2. LSP-Ping and BFD over ACH . . . . . . . . . . . . . . . . . 3
2. LSP-Ping extensions . . . . . . . . . . . . . . . . . . . . . . 3 2. LSP-Ping extensions . . . . . . . . . . . . . . . . . . . . . . 3
2.1. LSP-Ping packet over ACH for LSPs . . . . . . . . . . . . . 3 2.1. LSP-Ping packet over ACH for LSPs . . . . . . . . . . . . . 3
2.2. LSP-Ping packet over ACH for PWs . . . . . . . . . . . . . 4 2.2. LSP-Ping packet over ACH for PWs . . . . . . . . . . . . . 4
2.3. Source Address TLV . . . . . . . . . . . . . . . . . . . . 4 2.3. Source Address TLV . . . . . . . . . . . . . . . . . . . . 4
2.4. MEP and MIP Identifier . . . . . . . . . . . . . . . . . . 4 2.4. MEP and MIP Identifier . . . . . . . . . . . . . . . . . . 5
3. Running BFD over MPLS-TP LSPs . . . . . . . . . . . . . . . . . 5 3. Running BFD over MPLS-TP LSPs . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5.1. New ACH Channel Type . . . . . . . . . . . . . . . . . . . 6 5.1. New ACH Channel Types . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
LSP-Ping [RFC4379] and [I-D.ietf-bfd-mpls] are OAM mechanisms for LSP-Ping [RFC4379] and BFD for MPLS [RFC5884] are OAM mechanisms for
MPLS LSPs. This document describes ACH encapsulation for LSP-Ping, MPLS LSPs. This document describes an ACH encapsulation for LSP-Ping
to enable use of LSP-Ping when IP addressing is not in use. When IP for networks that do not use IP addressing. When IP addressing is in
addressing is in use, procedures specified in [RFC4379] apply as is. use, the LSP-Ping procedures specified in [RFC4379] apply as is.
This document also clarifies the use of BFD for MPLS LSPs using ACH This document also clarifies the use of BFD for MPLS LSPs using ACH
encapsulation, when IP addressing may not be available and/or it may encapsulation [RFC5586], when IP addressing may not be available
not be desirable to encapsulate BFD packets in IP. and/or it may not be desirable to encapsulate BFD packets in IP.
1.1. Conventions used in this document 1.1. Conventions used in this document
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. LSP-Ping and BFD over ACH 1.2. LSP-Ping and BFD over ACH
In certain MPLS-TP deployment scenarios IP addressing might not be In certain MPLS-TP deployment scenarios IP addressing might not be
available or it may be preferred to use non-IP encapsulation for LSP- available or it may be preferred to use non-IP encapsulation for LSP-
Ping and BFD packets. To enable re-use of OAM techniques provided by Ping and BFD packets. The remainder of this document defines
LSP-Ping and BFD in such networks, rest of this document defines extensions to LSP-Ping and procedures for using BFD, for such
extensions to LSP-Ping and procedures for using BFD. scenarios.
Sections Section 2.1 and Section 2.2 describe a new ACH code-point Section 2.1 and Section 2.2 describe a new ACH code-point for
for performing LSP-Ping over ACH. Section Section 3 describes performing LSP-Ping over ACH. Section 3 describes procedures for
procedures for using BFD over ACH. using BFD over ACH.
2. LSP-Ping extensions 2. LSP-Ping extensions
2.1. LSP-Ping packet over ACH for LSPs 2.1. LSP-Ping packet over ACH for LSPs
[RFC5586] defines an ACH mechanism for MPLS LSPs. This document [RFC5586] defines an ACH mechanism for MPLS LSPs. This document
defines a new ACH channel type for LSP-Ping, when IP addressing is defines a new ACH channel type for LSP-Ping, when IP addressing is
not in use, for LSP-Ping over associated bi-directional LSPs and co- not in use, for LSP-Ping over associated bi-directional LSPs and co-
routed bi-directional LSPs. routed bi-directional LSPs. ACH TLVs MAY be associated with this
channel type.
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 2 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | LSP-Ping Channel Type | |0 0 0 1|Version| Reserved | LSP-Ping Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: LSP-Ping ACH Channel Type Figure 1: LSP-Ping ACH Channel Type
When ACH header is used, an LSP-Ping packet will look as follows: When ACH header is used, an LSP-Ping packet will look as follows:
skipping to change at page 4, line 15 skipping to change at page 4, line 17
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 2 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label stack | | MPLS Label stack |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | | GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | LSP-Ping Channel Type | |0 0 0 1|Version| Reserved | LSP-Ping Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLVs | | ACH TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP-Ping payload | | LSP-Ping payload |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LSP-Ping packet with ACH Figure 2: LSP-Ping packet with ACH
When using LSP-Ping over the ACH header, the LSP-Ping Reply mode When using LSP-Ping over the ACH header, the LSP-Ping Reply mode
[RFC4379] in the LSP-Ping echo request MUST be set to 4 (Reply via [RFC4379] in the LSP-Ping echo request MUST be set to 4 (Reply via
skipping to change at page 4, line 40 skipping to change at page 4, line 45
[RFC4385] defines an PW-ACH mechanism for pseudowires. The ACH [RFC4385] defines an PW-ACH mechanism for pseudowires. The ACH
channel type for LSP-Ping defined in Section 2.1 will be re-used for channel type for LSP-Ping defined in Section 2.1 will be re-used for
pseudowires so that IP addressing is not needed when using LSP-Ping pseudowires so that IP addressing is not needed when using LSP-Ping
OAM over pseudowires. OAM over pseudowires.
2.3. Source Address TLV 2.3. Source Address TLV
When sending LSP-Ping packets using ACH, without IP encapsulation, When sending LSP-Ping packets using ACH, without IP encapsulation,
there MAY be a need to identify the source address of the packet. there MAY be a need to identify the source address of the packet.
This source address will be specified via the Source Address TLV, This source address will be specified via the Source Address TLV,
being defined in [I-D.ietf-mpls-tp-ach-tlv]. Only 1 source address being defined in [I-D.ietf-mpls-tp-ach-tlv]. No more than 1 source
TLV MUST be present in a LSP-Ping packet. The source address MUST address TLV MAY be present in a LSP-Ping packet. The source address
specify the address of the originator of the packet. If more than 1 MUST specify the address of the originator of the packet. If more
such TLV is present in a LSP-Ping request packet, then an error code than 1 such TLV is present in a LSP-Ping request packet, then an
of 1 (Malformed echo request received), [ Section 3.1 [RFC4379]], error code of 1 (Malformed echo request received), [ Section 3.1
SHOULD be returned. If more than 1 source address TLV is present, [RFC4379]], SHOULD be returned. If more than 1 source address TLV is
then the packet SHOULD be dropped without further processing. present, then the packet SHOULD be dropped without further
processing.
2.4. MEP and MIP Identifier 2.4. MEP and MIP Identifier
When sending LSP-Ping packets using ACH, there MAY be a need to When sending LSP-Ping packets using ACH, there MAY be a need to
identify the maintenance end point (MEP) and/or the maintenance identify the maintenance end point (MEP) and/or the maintenance
intermediate point (MIP) being monitored intermediate point (MIP) being monitored
[I-D.ietf-mpls-tp-rosetta-stone]. The MEP/MIP identifiers defined in [I-D.ietf-mpls-tp-rosetta-stone]. The MEP/MIP identifiers defined in
[I-D.ietf-mpls-tp-identifiers] MAY be carried in the ACH TLVs [I-D.ietf-mpls-tp-identifiers] MAY be carried in the ACH TLVs
[I-D.ietf-mpls-tp-ach-tlv] for identification. [I-D.ietf-mpls-tp-ach-tlv] for identification.
3. Running BFD over MPLS-TP LSPs 3. Running BFD over MPLS-TP LSPs
[I-D.ietf-bfd-mpls] describes how BFD can be used for Continuity [RFC5884] describes how BFD can be used for Continuity Check of MPLS
Check for MPLS LSPs. The procedures described in [I-D.ietf-bfd-mpls] LSPs. The procedures described in [RFC5884] MUST be used when IP
MUST be used when IP addressing is in use. This section clarifies encapsulation is in use. This section clarifies the usage of BFD in
the usage of BFD in the context of MPLS-TP LSPs when it is not the context of MPLS-TP LSPs when it is not desirable to use IP
desirable to use IP encapsulation. When using BFD over MPLS-TP LSPs, encapsulation. When using BFD over MPLS-TP LSPs, the BFD
the BFD discriminator MUST either be signaled via LSP-Ping or be discriminator MUST either be signaled via LSP-Ping or be statically
statically configured. The BFD packets MUST be sent over ACH when IP configured. The BFD packets MUST be sent over ACH when IP
encapsulation is not used. The ACH Channel type MUST be set to the encapsulation is not used.
value specified in [I-D.ietf-pwe3-vccv-bfd]. BFD packets, for both
directions, MUST be sent over the MPLS-TP LSP and IP forwarding This document defines a new ACH channel type for BFD over G-ACH, when
SHOULD NOT be used for the reverse path. The format of a BFD packet IP addressing is not in use, for running BFD over associated bi-
when using it as an OAM tool for MPLS-TP LSPs SHOULD be as follows: directional LSPs and co-routed bi-directional LSPs. ACH TLVs MAY be
associated with this channel type.
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | BFD over G-ACH Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: BFD over G-ACH Channel Type
BFD packets, for both directions, MUST be sent over the MPLS-TP LSP
and IP forwarding SHOULD NOT be used for the reverse path. The
format of a BFD packet when using it as an OAM tool for MPLS-TP LSPs
SHOULD be as follows:
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 2 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label stack | | MPLS Label stack |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | | GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type | |0 0 0 1|Version| Reserved | BFD over G-ACH Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLVs | | ACH TLVs |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD payload | | BFD payload |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: BFD packet over MPLS-TP LSPs Figure 4: BFD packet over MPLS-TP LSPs
[I-D.ietf-pwe3-vccv-bfd] specifies how BFD can be used over MPLS PWs. [RFC5885] specifies how BFD can be used over MPLS PWs. One MAY use
BFD over G-ACH channel type to run BFD over PWs if ACH TLV support is
needed.
BFD supports continuous fault monitoring and thus meets the pro- BFD supports continuous fault monitoring and thus meets the pro-
active Continuity Check and verification requirement specified in active Continuity Check and verification requirement specified in
[I-D.ietf-mpls-tp-oam-requirements]. BFD SHOULD be run pro-actively. [RFC5860]. BFD SHOULD be run pro-actively. This function SHOULD be
This function SHOULD be performed between End Points (MEPs) of PWs, performed between End Points (MEPs) of PWs, LSPs and Sections. For
LSPs and Sections. For point to multipoint Continuity Check, there point to multipoint Continuity Check, there is work in progress on
is work in progress on using BFD for P2MP MPLS LSPs ( using BFD for P2MP MPLS LSPs ( [I-D.katz-ward-bfd-multipoint]) and
[I-D.katz-ward-bfd-multipoint]) and this can be leveraged for MPLS-TP this can be leveraged for MPLS-TP LSPs as well. Failure of a BFD
LSPs as well. Failure of a BFD session over a LSP can be used to session over a LSP can be used to trigger protection switching or
trigger protection switching or other fault remedial procedures. other fault remedial procedures.
When sending BFD packets using ACH, there MAY be a need to identify When sending BFD packets using ACH, there MAY be a need to identify
the maintenance end point (MEP) and/or the maintenance intermediate the maintenance end point (MEP) being monitored. The MEP identifier
point (MIP) being monitored. The MEP/MIP identifiers defined in defined in [I-D.ietf-mpls-tp-identifiers] can be carried in the ACH
[I-D.ietf-mpls-tp-identifiers] can be carried in the ACH TLVs TLVs [I-D.ietf-mpls-tp-ach-tlv] for identification.
[I-D.ietf-mpls-tp-ach-tlv] for identification.
4. Security Considerations 4. Security Considerations
The draft does not introduce any new security considerations. Those The draft does not introduce any new security considerations. Those
discussed in [RFC4379] are also applicable to this document. discussed in [RFC4379] are also applicable to this document.
5. IANA Considerations 5. IANA Considerations
5.1. New ACH Channel Type 5.1. New ACH Channel Types
A new Channel type is defined in Section 2.1. IANA is requested to New Channels type are defined in Section 2.1 and Section 3. IANA is
assign a new value from the "PW Associated Channel Type" registry, as requested to assign new values from the "PW Associated Channel Type"
per IETF consensus policy. registry, as per IETF consensus policy.
Value Meaning Value Meaning
----- ------- ----- -------
TBD Associated Channel carries LSP-Ping packet TBD Associated Channel carries LSP-Ping packet
TBD Associated Channel carries BFD over G-ACH
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006. Use over an MPLS PSN", RFC 4385, February 2006.
6.2. Informative References 6.2. Informative References
[I-D.ietf-bfd-mpls]
Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"BFD For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in
progress), June 2008.
[I-D.ietf-mpls-tp-ach-tlv] [I-D.ietf-mpls-tp-ach-tlv]
Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., Ward, Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., Ward,
D., and V. Manral, "Definition of ACH TLV Structure", D., and V. Manral, "Definition of ACH TLV Structure",
draft-ietf-mpls-tp-ach-tlv-02 (work in progress), draft-ietf-mpls-tp-ach-tlv-02 (work in progress),
March 2010. March 2010.
[I-D.ietf-mpls-tp-identifiers] [I-D.ietf-mpls-tp-identifiers]
Bocci, M. and G. Swallow, "MPLS-TP Identifiers", Bocci, M. and G. Swallow, "MPLS-TP Identifiers",
draft-ietf-mpls-tp-identifiers-01 (work in progress), draft-ietf-mpls-tp-identifiers-02 (work in progress),
March 2010. July 2010.
[I-D.ietf-mpls-tp-oam-requirements]
Vigoureux, M. and D. Ward, "Requirements for OAM in MPLS
Transport Networks",
draft-ietf-mpls-tp-oam-requirements-06 (work in progress),
March 2010.
[I-D.ietf-mpls-tp-rosetta-stone] [I-D.ietf-mpls-tp-rosetta-stone]
Helvoort, H., Andersson, L., and N. Sprecher, "A Thesaurus Sprecher, N., "A Thesaurus for the Terminology used in
for the Terminology used in Multiprotocol Label Switching Multiprotocol Label Switching Transport Profile (MPLS-TP)
Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's drafts/RFCs and ITU-T's Transport Network
Transport Network Recommendations", Recommendations.", draft-ietf-mpls-tp-rosetta-stone-02
draft-ietf-mpls-tp-rosetta-stone-01 (work in progress), (work in progress), May 2010.
October 2009.
[I-D.ietf-pwe3-vccv-bfd]
Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)",
draft-ietf-pwe3-vccv-bfd-07 (work in progress), July 2009.
[I-D.katz-ward-bfd-multipoint] [I-D.katz-ward-bfd-multipoint]
Katz, D. and D. Ward, "BFD for Multipoint Networks", Katz, D. and D. Ward, "BFD for Multipoint Networks",
draft-katz-ward-bfd-multipoint-02 (work in progress), draft-katz-ward-bfd-multipoint-02 (work in progress),
February 2009. February 2009.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", RFC 5885, June 2010.
Authors' Addresses Authors' Addresses
Nitin Bahadur (editor) Nitin Bahadur (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Phone: +1 408 745 2000 Phone: +1 408 745 2000
Email: nitinb@juniper.net Email: nitinb@juniper.net
skipping to change at page 8, line 45 skipping to change at page 9, line 22
Email: dward@juniper.net Email: dward@juniper.net
URI: www.juniper.net URI: www.juniper.net
Thomas D. Nadeau Thomas D. Nadeau
BT BT
BT Centre BT Centre
81 Newgate Street 81 Newgate Street
London EC1A 7AJ London EC1A 7AJ
United Kingdom United Kingdom
Email: tom.nadeau@bt.co Email: tom.nadeau@bt.com
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B 3 Hanagar St. Neve Ne'eman B
Hod Hasharon 45241 Hod Hasharon 45241
Israel Israel
Phone: +972-9-775 1229 Phone: +972-9-775 1229
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
Yaacov Weingarten Yaacov Weingarten
 End of changes. 30 change blocks. 
90 lines changed or deleted 110 lines changed or added

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