One document matched: draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-00.txt
Network Working Group N. Bahadur, Ed.
Internet-Draft R. Aggarwal
Intended status: Standards Track Juniper Networks, Inc.
Expires: January 6, 2010 T. Nadeau
BT
N. Sprecher
Y. Weingarten
Nokia Siemens Networks
July 5, 2009
LSP-Ping and BFD for MPLS-TP
draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-00
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 January 6, 2010.
Copyright Notice
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.
Bahadur, et al. Expires January 6, 2010 [Page 1]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
Abstract
LSP-Ping and BFD for MPLS are existing and widely deployment OAM
mechanisms for MPLS LSPs. This document describes how LSP-Ping and
BFD for MPLS can be used to perform OAM on MPLS-TP LSPs. This
document describes extensions to LSP-Ping when IP addressing is not
in use, in a MPLS-TP deployment scenario. These extensions are also
meant to be applicable when it is desirable to avoid the use of IP
encapsulation for exchanging LSP-Ping OAM messages. This document
also clarifies the use of BFD for MPLS-TP LSPs when IP addressing may
not be available and/or it may not be desirable to encapsulate BFD
packets in IP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 4
1.2. Existing LSP-Ping and BFD for MPLS LSPs Encapsulation
Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Non-IP LSP-Ping and BFD for MPLS LSPs Encapsulation
Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 5
2. LSP-Ping extensions . . . . . . . . . . . . . . . . . . . . . 5
2.1. LSP-Ping packet over ACH . . . . . . . . . . . . . . . . . 5
2.2. LSP-Ping packet over PW-ACH . . . . . . . . . . . . . . . 6
2.3. New address type for Downstream Mapping TLV . . . . . . . 6
2.4. Source Address TLV . . . . . . . . . . . . . . . . . . . . 6
2.5. Destination Address TLV . . . . . . . . . . . . . . . . . 7
3. Performing LSP-Ping over MPLS-TP LSPs . . . . . . . . . . . . 7
3.1. Traditional LSP-Ping . . . . . . . . . . . . . . . . . . . 7
3.2. Non-IP based LSP-Ping . . . . . . . . . . . . . . . . . . 8
3.3. P2MP Considerations . . . . . . . . . . . . . . . . . . . 9
4. Performing LSP Traceroute over MPLS-TP LSPs . . . . . . . . . 9
4.1. Traditional LSP Traceroute . . . . . . . . . . . . . . . . 10
4.2. Non-IP based LSP Traceroute . . . . . . . . . . . . . . . 10
4.2.1. Ingress node procedure for sending echo request
packets . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Ingress node procedure for receiving echo response
packets . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. Transit and egress node procedure . . . . . . . . . . 10
4.3. P2MP Considerations . . . . . . . . . . . . . . . . . . . 11
4.4. ECMP Considerations . . . . . . . . . . . . . . . . . . . 11
5. Running BFD over MPLS-TP LSPs . . . . . . . . . . . . . . . . 11
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. New ACH Channel Type . . . . . . . . . . . . . . . . . . . 12
8.2. New LSP-Ping TLV Types . . . . . . . . . . . . . . . . . . 13
Bahadur, et al. Expires January 6, 2010 [Page 2]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Bahadur, et al. Expires January 6, 2010 [Page 3]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
1. Introduction
LSP-Ping [RFC4379] and [I-D.ietf-bfd-mpls] are OAM mechanisms for
MPLS LSPs. This document describes how LSP-Ping and BFD for MPLS can
be used to perform OAM on MPLS-TP LSPs. The document considers two
cases. The first is when IP addressing and host stack are available
on egress and transit LSRs. The second is when such capabilities are
either not available or it is not desirable to use them.
Sections Section 3.2 and Section 4.2 describes the theory of
operation for performing LSP-Ping over MPLS-TP LSPs. Section
Section 2.1 describes the new TLVs and LSP-Ping extensions for
performing LSP-Ping in the absence of IP addressing.
1.1. Conventions used in this document
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 [RFC2119].
1.2. Existing LSP-Ping and BFD for MPLS LSPs Encapsulation Mechanism
LSP-Ping requires IP addressing on the egress and transit LSRs for
performing OAM on MPLS signaled LSPs and pseudowires. BFD for MPLS
LSPs also requires IP addressing. In particular, in these cases the
LSP-Ping and BFD packets generated by an ingress LSR are encapsulated
in an IP/UDP header with the destination address from the 127/8 range
and then encapsulated in the MPLS label stack ([RFC4379] ,
[I-D.ietf-bfd-mpls]). Egress LSRs use the presence of the 127/8
destination address to identify the OAM packets and rely further on
the UDP port number to determine whether the packet is a LSP-Ping or
a BFD packet. It is to be noted that this determination does not
require IP forwarding capabilities. It requires the presence of an
IP host stack which enables egress LSRs to process packets with a
destination address from the 127/8 range. [RFC1122] allocates the
127/8 range as "Internal host loopback address" and [RFC1812] states
that "a router SHOULD NOT forward, except over a loopback interface,
any packet that has a destination address on network 127".
LSP-Ping and BFD for MPLS specify procedures that allow an egress LSR
to use a MPLS LSP for forwarding LSP-Ping or BFD packets to the
ingress LSR. This ensures that IP forwarding capabilities are not
required and meets the MPLS-TP requirement of not having IP
forwarding capabilities.
[I-D.ietf-mpls-tp-framework] specifies that IP addressing is the
default addressing mechanism for MPLS-TP networks. An IP host stack
must be present when IP addressing is in use. This implies that
Bahadur, et al. Expires January 6, 2010 [Page 4]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
exisiting LSP-Ping and BFD procedures can be used as is in MPLS-TP
environments when IP addressing is in use.
1.3. Non-IP LSP-Ping and BFD for MPLS LSPs Encapsulation Mechanism
In certain MPLS-TP deployment scenarios IP addressing might not be
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
LSP-Ping and BFD in such networks, rest of this document defines
extensions to LSP-Ping and procedures for using BFD. The document
defines a new code-point for using LSP-Ping with an ACH header.
Further, it describes how LSP-Ping can be used to perform
Connectivity Verification, Route Tracing and Adjacency functions
specified in [I-D.ietf-mpls-tp-oam-requirements]. This document also
clarifies the usage of BFD in the context of MPLS-TP LSPs.
Sections Section 3.2 and Section 4.2 describe the theory of operation
for performing LSP-Ping over MPLS-TP LSPs with a non-IP
encapsulation. Section 2.1 describes the new TLVs and LSP-Ping
extensions for performing LSP-Ping in the absence of IP addressing.
Section 5 describes procedures for using BFD with non-IP
encapsulation."
2. LSP-Ping extensions
2.1. LSP-Ping packet over ACH
[RFC5586] defines an ACH mechanism for MPLS LSPs. This document
defines a new ACH channel type for when IP addressing is not in use
for LSP-Ping over associated bi-directional LSPs and co-routed bi-
directional LSPs.
ACH TLVs CANNOT be associated with LSP-Ping 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 | LSP-Ping Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: LSP-Ping ACH Channel Type
Bahadur, et al. Expires January 6, 2010 [Page 5]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
2.2. LSP-Ping packet over PW-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
pseudowires so that IP addressing is not needed when using LSP-Ping
OAM over pseudowires.
2.3. New address type for Downstream Mapping TLV
[RFC4379] defines the Downstream Mapping TLV. A new type is being
added to the Address Type field as follows:
Type # Address Type K Octets
------ -------------- --------
0 Not Applicable 8
Figure 2: Downstream Mapping TLV new Address Type
The new address type indicates that no address is present in the
Downstream Mapping TLV. Multipath type MAY be set to 0 (no mutlpath)
when using this address type.
When this address type is used, on receipt of a lsp-ping echo
request, both interface verification and label stack validation MUST
be bypassed.
The new address type is also applicable to the Detailed Downstream
Mapping TLV defined in [I-D.ietf-mpls-lsp-ping-enhanced-dsmap].
2.4. Source Address TLV
A new optional TLV is being defined for encapsulating the source
address. The optional TLV will be part of the TLVs defined in
[RFC4379]. Only 1 source address TLV MUST be present in a LSP-Ping
packet. The source address MUST specify the address of the
originator of the packet. If more than 1 such TLV is present in a
LSP-Ping request packet, then an error of "Malformed echo request
received" SHOULD be returned. If more than 1 source address TLV is
present in a LSP-Ping response packet, then the packet SHOULD be
dropped without further processing. The source address TLV MUST NOT
be used if IP addressing is in use. If IP addressing is in use, then
one should use lsp-ping with IP.
The format of the TLV is TBD.
Bahadur, et al. Expires January 6, 2010 [Page 6]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
2.5. Destination Address TLV
A new optional TLV is being defined for encapsulating the destination
address. The optional TLV will be part of the TLVs defined in
[RFC4379]. One or more of this TLV MAY be included in a LSP-Ping
request message. If more than 1 destination address TLV is present
in a LSP-Ping response packet, then the packet SHOULD be dropped
without further processing. The destination address MUST specify the
intended receipient(s) of the packet. If the destination address
specified in any of the Destination Address TLVs does not match any
address associated with the node which receives the LSP-Ping packet,
then the LSP-Ping packet SHOULD be dropped without further
processing. The destination address TLV MUST NOT be used if IP
addressing is in use. If IP addressing is in use, then one should
use lsp-ping with IP.
The format of the TLV is TBD.
3. Performing LSP-Ping over MPLS-TP LSPs
This section specifies how LSP-Ping ping can be used in the context
of MPLS-TP LSPs. The LSP-Ping ping function meets the Connectivity
Verification requirement specified in
[I-D.ietf-mpls-tp-oam-requirements].
3.1. Traditional LSP-Ping
Traditional LSP-Ping packets ride over the LSP and contain an IP/UDP
packet within them. The IP header is not used for forwarding (since
the LSP is forwarded using MPLS label switching). The IP header is
used mainly for addressing and can be used in the context of MPLS-TP
LSPs. This form of LSP-Ping OAM MUST be supported for MPLS-TP LSPs
when IP addressing is in use. The figure below shows an MPLS-TP LSP-
Ping OAM packet.
Bahadur, et al. Expires January 6, 2010 [Page 7]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label stack |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP/UDP Headers |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP-Ping payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: LSP-Ping packet
The LSP-Ping Reply mode [RFC4379] in the LSP-Ping echo request MUST
be set to 4 (Reply via application level control channel).
The LSP-Ping reply message MUST be sent on the reverse path of the
LSP. The reply MUST contain IP/UDP headers followed by the LSP-Ping
payload. The destination address in the IP header MUST be set to
that of the sender of the request message. The source adderss in the
IP header MUST be set to a valid address of the replying node.
3.2. Non-IP based LSP-Ping
The OAM procedures defined in [RFC4379] require the use of IP
addressing and in some cases IP routing to perform OAM functions.
When the ACH header is used, IP addressing and routing is not needed.
This section describes procedures for performing lsp-ping without a
dependency on IP.
When ACH header is used, an LSP-Ping packet will look as follows:
Bahadur, et al. Expires January 6, 2010 [Page 8]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label stack |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | LSP-Ping Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP-Ping payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: LSP-Ping packet with ACH
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
application level control channel).
The ingress node MAY attach a Source Address TLV (Section 2.4) to
identify the node originating the request.
The LSP-Ping reply message MUST be sent on the reverse path of the
LSP using ACH. The LSP-Ping payload MUST directly follow the ACH
header and no IP and/or UDP headers MUST be attached. If the request
message contained the Source Address TLV and a response is being sent
to the originator, then a Destination Address TLV (Section 2.5)
SHOULD be added to the reply message. The contents of the LSP-Ping
request Source Address TLV should be copied into the LSP-Ping
response Destination Address TLV. The responding node MAY attach a
Source Address TLV to identify the node sending the response.
3.3. P2MP Considerations
[I-D.ietf-mpls-p2mp-lsp-ping] describes how LSP-Ping can be used for
OAM on P2MP LSPs. The procedures described in this draft apply as is
irrespective of whether we use the mechanism specified in Section 3.1
or the mechanism specified in Section 3.2.
4. Performing LSP Traceroute over MPLS-TP LSPs
This section specifies how LSP-Ping traceroute can be used in the
context of MPLS-TP LSPs. The LSP-Ping traceroute function meets the
Adjancency and Route Tracing requirement specified in
[I-D.ietf-mpls-tp-oam-requirements].
Bahadur, et al. Expires January 6, 2010 [Page 9]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
When performing lsp-ping traceroute, the ingress node inserts a
Downstream Mapping TLV to get the downstream node information and to
enable LSP verification along the transit nodes. The Downstream
mapping TLV can be used as is for performing the traceroute. If IP
addressing is not in use, then the Address Type field in the
Downstream Mapping TLV can be set to "Not applicable" (Section 2.3).
The Downstream Mapping TLV address type field can be extended to
include other address types as need be.
4.1. Traditional LSP Traceroute
The mechanics of LSP-Ping traceroute are similar to those described
for ping in Section 3.1. Traceroute packets sent by the lsp ingress
MUST adhere to the format described in Section 3.2.This form of LSP-
Ping OAM MUST be supported for MPLS-TP LSPs, when IP addressing is in
use.
4.2. Non-IP based LSP Traceroute
This section describes the procedures for performing lsp-traceroute
when using the ACH header and without any dependency on IP
addressing. The procedures specified in Section 3.2 with regards to
Source Address TLV and Destination Address TLV apply to LSP
traceroute as well.
4.2.1. Ingress node procedure for sending echo request packets
Traceroute packets sent by the lsp ingress MUST adhere to the format
described in Section 3.2. MPLS-TTL expiry (as described in
[RFC4379]) will be used to direct the packets to specific nodes along
the LSP path.
4.2.2. Ingress node procedure for receiving echo response packets
The lsp-ping traceroute responses will be received on the LSP itself
and the presence of an ACH header with channel type of LSP-Ping is an
indicator that the packet contains LSP-ping payload.
4.2.3. Transit and egress node procedure
When a echo request reaches the transit or egress, the presence of
the ACH channel type of LSP-Ping will indicate that the packet
contains LSP-Ping data. The LSP-Ping data and the label stack should
be able to identify the LSP associated with the echo request packet.
In case if there is an error and the node is unable to idenfity the
LSP on which the echo response should to be sent, the node MUST drop
the echo request packet and not send any response back. All
responses MUST always be sent on a LSP path using the ACH header and
Bahadur, et al. Expires January 6, 2010 [Page 10]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
ACH channel type of LSP-Ping.
4.3. P2MP Considerations
[I-D.ietf-mpls-p2mp-lsp-ping] describes how LSP-Ping can be used for
OAM on P2MP LSPs. The procedures described in this draft apply as is
irrespective of whether we use the mechanism specified in Section 4.1
or the mechanism specified in Section 4.2.
4.4. ECMP Considerations
LSP-Ping using ACH SHOULD NOT be used when there is ECMP (equal cost
multiple paths) for a given LSP. The addition of the additional ACH
header may modify the hashing behavior for OAM packets which may
result in incorrect modeling of path taken by data traffic.
5. Running BFD over MPLS-TP LSPs
[I-D.ietf-bfd-mpls] describes how BFD can be used for Continuity
Check for MPLS LSPs. When IP addressing is in use, the procedures
described in [I-D.ietf-bfd-mpls] apply as is. This section clarifies
the usage of BFD in the context of MPLS-TP LSPs when it is not
desirable to use IP encapsulation. When using BFD over MPLS-TP LSPs,
the BFD descriminator MAY either be signaled via LSP-Ping or be
statically configured. The BFD packets MUST be sent over ACH when IP
encapsulation is not used. 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 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload depending on channel type |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: BFD packet over MPLS-TP LSPs
Bahadur, et al. Expires January 6, 2010 [Page 11]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
[I-D.ietf-pwe3-vccv-bfd] specifies how BFD can be used over MPLS PWs.
Of specific interest are 2 modes:
1. Channel type is IP and payload contains BFD packet with IP/UDP
headers.
2. Channel type is BFD and payload contains BFD packet without IP/
UDP headers.
The first mode MUST be supported for BFD over MPLS-TP LSPs. The
second mode MAY be supported in addition.
Thus, no changes in BFD and no new code-points are needed to run BFD
over MPLS-TP LSPs. BFD supports continuous fault monitoring and thus
meets the Continuity Check requirement specified in
[I-D.ietf-mpls-tp-oam-requirements]. For point to multipoint
Continuity Check, there is work in progress on using BFD for P2MP
MPLS LSPs ( [I-D.katz-ward-bfd-multipoint]) and this can be leveraged
for MPLS-TP LSPs as well.
6. Applicability
The procedures described in this document apply to MPLS LSPs and as
well as to LSPs based on the MPLS-TP profile. The LSP-Ping
procedures can be used for performing OAM on both LSPs and
Pseudowires.
7. Security Considerations
The draft does not introduce any new security considerations. Those
discussed in [RFC4379] are also applicable to this document.
8. IANA Considerations
8.1. New ACH Channel Type
A new Channel type is defined in Section 2.1. IANA is requested to
assign a new value from the "PW Associated Channel Type" registry, as
per IETF consensus policy.
Value Meaning
----- -------
TBD Associated Channel carries LSP-Ping packet
Bahadur, et al. Expires January 6, 2010 [Page 12]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
8.2. New LSP-Ping TLV Types
New TLV types are defined in Section 2.4 and Section 2.5. IANA is
requested to assign values from the "Multi-Protocol Label Switching
(MPLS) Label Switched Paths (LSPs) Parameters" registry, "TLVs and
sub-TLVs" sub- registry from the range of 32768-64511.
Value Meaning
----- -------
TBD Source Address
TBD Destination Address
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
9.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-lsp-ping-enhanced-dsmap]
Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
performing LSP-Ping over MPLS tunnels",
draft-ietf-mpls-lsp-ping-enhanced-dsmap-02 (work in
progress), February 2009.
[I-D.ietf-mpls-p2mp-lsp-ping]
Yasukawa, S., Farrel, A., Ali, Z., Fenner, B., Swallow,
G., and T. Nadeau, "Detecting Data Plane Failures in
Point-to-Multipoint Multiprotocol Label Switching (MPLS)
- Extensions to LSP Ping",
draft-ietf-mpls-p2mp-lsp-ping-07 (work in progress),
Bahadur, et al. Expires January 6, 2010 [Page 13]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
September 2008.
[I-D.ietf-mpls-tp-framework]
Bocci, M., Bryant, S., and L. Levrau, "A Framework for
MPLS in Transport Networks",
draft-ietf-mpls-tp-framework-01 (work in progress),
June 2009.
[I-D.ietf-mpls-tp-oam-requirements]
Vigoureux, M., Ward, D., and M. Betts, "Requirements for
OAM in MPLS Transport Networks",
draft-ietf-mpls-tp-oam-requirements-02 (work in progress),
June 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-05 (work in progress), June 2009.
[I-D.katz-ward-bfd-multipoint]
Katz, D. and D. Ward, "BFD for Multipoint Networks",
draft-katz-ward-bfd-multipoint-02 (work in progress),
February 2009.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
Authors' Addresses
Nitin Bahadur (editor)
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Phone: +1 408 745 2000
Email: nitinb@juniper.net
URI: www.juniper.net
Bahadur, et al. Expires January 6, 2010 [Page 14]
Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009
Rahul Agrawal
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Phone: +1 408 745 2000
Email: rahul@juniper.net
URI: www.juniper.net
Thomas D. Nadeau
BT
BT Centre
81 Newgate Street
London EC1A 7AJ
United Kingdom
Email: tom.nadeau@bt.com
Nurit Sprecher
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon 45241
Israel
Phone: +972-9-775 1229
Email: nurit.sprecher@nsn.com
Yaacov Weingarten
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon 45241
Israel
Phone: +972-9-775 1827
Email: yaacov.weingarten@nsn.com
Bahadur, et al. Expires January 6, 2010 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 17:12:34 |