draft-ietf-mpls-lsp-ping-12.txt   draft-ietf-mpls-lsp-ping-13.txt 
Network Working Group Kireeti Kompella Network Working Group Kireeti Kompella
Internet Draft Juniper Networks, Inc. Internet Draft Juniper Networks, Inc.
Category: Standards Track Category: Standards Track
Expiration Date: June 2006 Expiration Date: July 2006
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
December 2005 January 2006
Detecting MPLS Data Plane Failures Detecting MPLS Data Plane Failures
draft-ietf-mpls-lsp-ping-12.txt draft-ietf-mpls-lsp-ping-13.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
3.1 Return Codes .............................................. 12 3.1 Return Codes .............................................. 12
3.2 Target FEC Stack .......................................... 13 3.2 Target FEC Stack .......................................... 13
3.2.1 LDP IPv4 Prefix ........................................... 14 3.2.1 LDP IPv4 Prefix ........................................... 14
3.2.2 LDP IPv6 Prefix ........................................... 14 3.2.2 LDP IPv6 Prefix ........................................... 14
3.2.3 RSVP IPv4 LSP ............................................. 15 3.2.3 RSVP IPv4 LSP ............................................. 15
3.2.4 RSVP IPv6 LSP ............................................. 15 3.2.4 RSVP IPv6 LSP ............................................. 15
3.2.5 VPN IPv4 Prefix ........................................... 16 3.2.5 VPN IPv4 Prefix ........................................... 16
3.2.6 VPN IPv6 Prefix ........................................... 17 3.2.6 VPN IPv6 Prefix ........................................... 17
3.2.7 L2 VPN Endpoint ........................................... 17 3.2.7 L2 VPN Endpoint ........................................... 17
3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 18 3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 18
3.2.9 FEC 128 Pseudowire (Current) .............................. 18 3.2.9 FEC 128 Pseudowire (Current) .............................. 19
3.2.10 FEC 129 Pseudowire ........................................ 19 3.2.10 FEC 129 Pseudowire ........................................ 19
3.2.11 BGP Labeled IPv4 Prefix ................................... 19 3.2.11 BGP Labeled IPv4 Prefix ................................... 20
3.2.12 BGP Labeled IPv6 Prefix ................................... 20 3.2.12 BGP Labeled IPv6 Prefix ................................... 21
3.2.13 Generic IPv4 Prefix ....................................... 20 3.2.13 Generic IPv4 Prefix ....................................... 21
3.2.14 Generic IPv6 Prefix ....................................... 21 3.2.14 Generic IPv6 Prefix ....................................... 22
3.2.15 Nil FEC ................................................... 21 3.2.15 Nil FEC ................................................... 22
3.3 Downstream Mapping ........................................ 22 3.3 Downstream Mapping ........................................ 23
3.3.1 Multipath Information Encoding ............................ 26 3.3.1 Multipath Information Encoding ............................ 27
3.3.2 Downstream Router and Interface ........................... 28 3.3.2 Downstream Router and Interface ........................... 29
3.4 Pad TLV ................................................... 28 3.4 Pad TLV ................................................... 30
3.5 Vendor Enterprise Number .................................. 29 3.5 Vendor Enterprise Number .................................. 30
3.6 Interface and Label Stack ................................. 29 3.6 Interface and Label Stack ................................. 31
3.7 Errored TLVs .............................................. 31 3.7 Errored TLVs .............................................. 32
3.8 Reply TOS Byte TLV ........................................ 31 3.8 Reply TOS Byte TLV ........................................ 33
4 Theory of Operation ....................................... 32 4 Theory of Operation ....................................... 33
4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 32 4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 33
4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 33 4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 34
4.3 Sending an MPLS Echo Request .............................. 33 4.3 Sending an MPLS Echo Request .............................. 35
4.4 Receiving an MPLS Echo Request ............................ 34 4.4 Receiving an MPLS Echo Request ............................ 36
4.4.1 FEC Validation ............................................ 40 4.4.1 FEC Validation ............................................ 41
4.5 Sending an MPLS Echo Reply ................................ 41 4.5 Sending an MPLS Echo Reply ................................ 42
4.6 Receiving an MPLS Echo Reply .............................. 42 4.6 Receiving an MPLS Echo Reply .............................. 43
4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 42 4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 44
4.8 Non-compliant Routers ..................................... 43 4.8 Non-compliant Routers ..................................... 44
5 References ................................................ 43 5 References ................................................ 44
6 Security Considerations ................................... 44 6 Security Considerations ................................... 46
7 IANA Considerations ....................................... 45 7 IANA Considerations ....................................... 47
7.1 Message Types, Reply Modes, Return Codes .................. 46 7.1 Message Types, Reply Modes, Return Codes .................. 47
7.2 TLVs ...................................................... 47 7.2 TLVs ...................................................... 48
8 Acknowledgments ........................................... 48 8 Acknowledgments ........................................... 49
1. Introduction 1. Introduction
This document describes a simple and efficient mechanism that can be This document describes a simple and efficient mechanism that can be
used to detect data plane failures in MPLS LSPs. There are two parts used to detect data plane failures in MPLS LSPs. There are two parts
to this document: information carried in an MPLS "echo request" and to this document: information carried in an MPLS "echo request" and
"echo reply"; and mechanisms for transporting the echo reply. The "echo reply"; and mechanisms for transporting the echo reply. The
first part aims at providing enough information to check correct first part aims at providing enough information to check correct
operation of the data plane, as well as a mechanism to verify the operation of the data plane, as well as a mechanism to verify the
data plane against the control plane, and thereby localize faults. data plane against the control plane, and thereby localize faults.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
The IPv4 link local addresses are more attractive in that scope over The IPv4 link local addresses are more attractive in that scope over
which they can be forwarded is limited. However, if one were to use which they can be forwarded is limited. However, if one were to use
an address from this range, it would still be possible for the first an address from this range, it would still be possible for the first
recipient of a diagnostic packet that "escaped" from a broken LSP to recipient of a diagnostic packet that "escaped" from a broken LSP to
have that addressed assigned to the interface on which it arrived and have that addressed assigned to the interface on which it arrived and
thus could mistakenly receive such a packet. Further, the IPv4 link thus could mistakenly receive such a packet. Further, the IPv4 link
local address range has only recently been allocated. Many deployed local address range has only recently been allocated. Many deployed
routers would forward a packet with an address from that range toward routers would forward a packet with an address from that range toward
the default route. the default route.
The 127/8 range for IPv4 and that same range embedded in an IPv6 The 127/8 range for IPv4 and that same range embedded in as
addresses for IPv6 was chosen for a number of reasons. IPv4-mapped IPv6 addresses for IPv6 was chosen for a number of rea-
sons.
RFC1122 allocates the 127/8 as "Internal host loopback address" and RFC1122 allocates the 127/8 as "Internal host loopback address" and
states that "Addresses of this form MUST NOT appear outside a host." states that "Addresses of this form MUST NOT appear outside a host."
Thus the default behavior of hosts is to discard such packets. This Thus the default behavior of hosts is to discard such packets. This
helps to ensure that if a diagnostic packet is mis-directed to a helps to ensure that if a diagnostic packet is mis-directed to a
host, it will be silently discarded. host, it will be silently discarded.
RFC1812 [RFC1812] states that: RFC1812 [RFC1812] states that:
A router SHOULD NOT forward, except over a loopback interface, any A router SHOULD NOT forward, except over a loopback interface, any
skipping to change at page 17, line 5 skipping to change at page 16, line 51
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Route Distinguisher (RD) is an 8-octect identifier; it does not
contain any inherent information. The purpose of the RD is solely to
allow one to create distinct routes to a common IPv4 address prefix.
The encoding of the RD is not important here. When matching this
field to the local FEC information, it is treated as an opaque value.
3.2.6. VPN IPv6 Prefix 3.2.6. VPN IPv6 Prefix
VPN-IPv6 NLRI (Network Layer Routing Information) is defined in VPN-IPv6 NLRI (Network Layer Routing Information) is defined in
[MPLS-L3-VPN]. This document uses the term VPN IPv6 prefix for a [MPLS-L3-VPN]. This document uses the term VPN IPv6 prefix for a
VPN-IPv6 NLRI which has been advertised with an MPLS label in BGP. VPN-IPv6 NLRI which has been advertised with an MPLS label in BGP.
See [BGP-LABEL]. See [BGP-LABEL].
When a VPN IPv6 prefix is encoded in a label stack, the following When a VPN IPv6 prefix is encoded in a label stack, the following
format is used. The value field consists of the Route Distinguisher format is used. The value field consists of the Route Distinguisher
advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0
skipping to change at page 17, line 31 skipping to change at page 17, line 35
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix | | IPv6 prefix |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Route Distiguisher is identical to the VPN IPv4 Prefix RD, except
that it functions here to allow the creation of distict routes to
IPv6 prefixes. See section 3.2.5. When matching this field to local
FEC information, it is treated as an opaque value.
3.2.7. L2 VPN Endpoint 3.2.7. L2 VPN Endpoint
VPLS BGP NLRI and VE ID are defined in [VPLS]. This document uses VPLS stands for Virtual Private Lan Service. The terms VPLS BGP NLRI
the simpler term L2 VPN endpoint when referring to a VPLS BGP NLRI. and VE ID (VPLS Edge Identifier) are defined in [VPLS-BGP]. This
document uses the simpler term L2 VPN endpoint when referring to a
VPLS BGP NLRI. The Route Distiguisher is 8-octet identifier used to
distinguish information about various L2 VPNs advertised by a node.
The VE ID is 2-octet identifier used to identify a particular node
which serves as the service attachment point within a VPLS. The
structure of these two identifiers is uninportant here; when matching
these fields to local FEC information, they are treated as opaque
values. The encapsulation type is identical to the PW Type in sec-
tion 3.2.8 below.
When an L2 VPN endpoint is encoded in a label stack, the following When an L2 VPN endpoint is encoded in a label stack, the following
format is used. The value field consists of a Route Distinguisher (8 format is used. The value field consists of a Route Distinguisher (8
octets), the sender (of the ping)'s VE ID (2 octets), the receiver's octets), the sender (of the ping)'s VE ID (2 octets), the receiver's
VE ID (2 octets), and an encapsulation type (2 octets), formatted as VE ID (2 octets), and an encapsulation type (2 octets), formatted as
follows: 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's VE ID | Receiver's VE ID | | Sender's VE ID | Receiver's VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero | | Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.8. FEC 128 Pseudowire (Deprecated) 3.2.8. FEC 128 Pseudowire (Deprecated)
FEC 128 and the term VC ID are defined in [PW-CONTROL]. When a FEC FEC 128 (0x80) is defined in [PW-CONTROL], as are the terms PW ID
128 is encoded in a label stack, the following format is used. The (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero
value field consists of the remote PE address (the destination 32-bit connection ID. The PW Type is a 15 bit number indicating the
address of the targeted LDP session), a VC ID and an encapsulation encapsultion type. It is carried right justified in the field below
type, as follows: termed encapsulation type with the high-order bit set to zero. Both
of these fields are treated in this protocol as opaque values.
When a FEC 128 is encoded in a label stack, the following format is
used. The value field consists of the remote PE address (the desti-
nation address of the targeted LDP session), the PW ID and the encap-
sulation type 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address | | Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC ID | | PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero | | PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This FEC is deprecated and is retained only for backward compatibil- This FEC is deprecated and is retained only for backward compatibil-
ity. Implementations of LSP ping SHOULD accept and process this TLV, ity. Implementations of LSP ping SHOULD accept and process this TLV,
but SHOULD send LSP ping echo requests with the new TLV (see next but SHOULD send LSP ping echo requests with the new TLV (see next
section), unless explicitly configured to use the old TLV. section), unless explicitly configured to use the old TLV.
An LSR receiving this TLV SHOULD use the source IP address of the LSP An LSR receiving this TLV SHOULD use the source IP address of the LSP
echo request to infer the Sender's PE Address. echo request to infer the Sender's PE Address.
3.2.9. FEC 128 Pseudowire (Current) 3.2.9. FEC 128 Pseudowire (Current)
skipping to change at page 18, line 33 skipping to change at page 19, line 14
This FEC is deprecated and is retained only for backward compatibil- This FEC is deprecated and is retained only for backward compatibil-
ity. Implementations of LSP ping SHOULD accept and process this TLV, ity. Implementations of LSP ping SHOULD accept and process this TLV,
but SHOULD send LSP ping echo requests with the new TLV (see next but SHOULD send LSP ping echo requests with the new TLV (see next
section), unless explicitly configured to use the old TLV. section), unless explicitly configured to use the old TLV.
An LSR receiving this TLV SHOULD use the source IP address of the LSP An LSR receiving this TLV SHOULD use the source IP address of the LSP
echo request to infer the Sender's PE Address. echo request to infer the Sender's PE Address.
3.2.9. FEC 128 Pseudowire (Current) 3.2.9. FEC 128 Pseudowire (Current)
FEC 128 and the term VC ID are defined in [PW-CONTROL]. When a FEC FEC 128 (0x80) is defined in [PW-CONTROL], as are the terms PW ID
128 is encoded in a label stack, the following format is used. The (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero
value field consists of the sender's PE address (the source address 32-bit connection ID. The PW Type is a 15 bit number indicating the
of the targeted LDP session), the remote PE address (the destination encapsultion type. It is carried right justified in the field below
address of the targeted LDP session), a VC ID and an encapsulation termed encapsulation type with the high-order bit set to zero.
type, as follows:
Both of these fields are treated in this protocol as opaque values.
When matching these field to the local FEC information, the match
MUST be exact.
When a FEC 128 is encoded in a label stack, the following format is
used. The value field consists of the sender's PE address (the
source address of the targeted LDP session), the remote PE address
(the destination address of the targeted LDP session), the PW ID and
the encapsulation type 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address | | Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address | | Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC ID | | PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero | | PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.10. FEC 129 Pseudowire 3.2.10. FEC 129 Pseudowire
FEC 129 and the terms AII, AGI, SAII, and TAII are defined in [PW- FEC 129 (0x81) and the terms PW Type, Attachment Group Identifier
CONTROL]. When a FEC 129 is encoded in a label stack, the following (AGI), Attachment Group Identifier Type (AGI Type), Attachment Indi-
format is used. The Length of this TLV is 16 + AGI length + SAII vidual Identifier Type (AII Type), Source Attachment Individual Iden-
length + TAII length. Padding is used to make the total length a tifier (SAII), Target Attachment Individual Identifier (TAII) are
multiple of 4; the length of the padding is not included in the defined in [PW-CONTROL]. The PW Type is a 15 bit number indicating
Length field. the encapsultion type. It is carried right justified in the field
below PW type with the high-order bit set to zero. All the other
fields are treated as opaque values and copied directly from the FEC
129 format. All of these values together uniquely define the FEC
with in the scope of the LDP session identified by the source and
remote PE addresses.
When a FEC 129 is encoded in a label stack, the following format is
used. The Length of this TLV is 16 + AGI length + SAII length + TAII
length. Padding is used to make the total length a multiple of 4;
the length of the padding is not included in the Length field.
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address | | Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address | | Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length | | PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 22 skipping to change at page 26, line 22
Multipath Type Multipath Type
The following Multipath Types are defined: The following Multipath Types are defined:
Key Type Multipath Information Key Type Multipath Information
--- ---------------- --------------------- --- ---------------- ---------------------
0 no multipath Empty (Multipath Length = 0) 0 no multipath Empty (Multipath Length = 0)
2 IP address IP addresses 2 IP address IP addresses
4 IP address range low/high address pairs 4 IP address range low/high address pairs
8 Bit-masked IPv4 IP address prefix and bit mask 8 Bit-masked IP IP address prefix and bit mask
address set address set
9 Bit-masked label set Label prefix and bit mask 9 Bit-masked label set Label prefix and bit mask
Type 0 indicates that all packets will be forwarded out this one Type 0 indicates that all packets will be forwarded out this one
interface. interface.
Types 2, 4, 8 and 9 specify that the supplied Multipath Information Types 2, 4, 8 and 9 specify that the supplied Multipath Information
will serve to exercise this path. will serve to exercise this path.
Depth Limit Depth Limit
skipping to change at page 26, line 35 skipping to change at page 27, line 35
1 Static 1 Static
2 BGP 2 BGP
3 LDP 3 LDP
4 RSVP-TE 4 RSVP-TE
3.3.1. Multipath Information Encoding 3.3.1. Multipath Information Encoding
The multipath information encodes labels or addresses which will The multipath information encodes labels or addresses which will
exercise this path. The multipath information depends on the multi- exercise this path. The multipath information depends on the multi-
path type. The contents of the field are shown in the table above. path type. The contents of the field are shown in the table above.
IP addresses are drawn from the range 127/8. Labels are treated as IPv4 addresses are drawn from the range 127/8; IPv6 addresses are
drawn from the range 0:0:0:0:0:FFFF:127/104. Labels are treated as
numbers, i.e. they are right justified in the field. For Type 4, numbers, i.e. they are right justified in the field. For Type 4,
ranges indicated by Address pairs MUST NOT overlap and MUST be in ranges indicated by Address pairs MUST NOT overlap and MUST be in
ascending sequence. ascending sequence.
Type 8 allows a denser encoding of IP address. The IPv4 prefix is Type 8 allows a denser encoding of IP address. The IP prefix is for-
formatted as a base IPv4 address with the non-prefix low order bits matted as a base IP address with the non-prefix low order bits set to
set to zero. The maximum prefix length is 27. Following the prefix zero. The maximum prefix length is 27. Following the prefix is a
is a mask of length 2^(32-prefix length) bits. Each bit set to one mask of length 2^(32-prefix length) bits for IPv4 and 2^(128-prefix
represents a valid address. The address is the base IPv4 address length) bits for IPv6. Each bit set to one represents a valid
plus the position of the bit in the mask where the bits are numbered address. The address is the base IPv4 address plus the position of
left to right beginning with zero. For example the IP addresses the bit in the mask where the bits are numbered left to right begin-
127.2.1.0, 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be ning with zero. For example the IPv4 addresses 127.2.1.0,
encoded as follows: 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be encoded 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 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 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| |0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0| |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Those same addresses embedded in IPv6 would be encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 9 allows a denser encoding of Labels. The label prefix is for- Type 9 allows a denser encoding of Labels. The label prefix is for-
matted as a base label value with the non-prefix low order bits set matted as a base label value with the non-prefix low order bits set
to zero. The maximum prefix (including leading zeros due to encod- to zero. The maximum prefix (including leading zeros due to encod-
ing) length is 27. Following the prefix is a mask of length ing) length is 27. Following the prefix is a mask of length
2^(32-prefix length) bits. Each bit set to one represents a valid 2^(32-prefix length) bits. Each bit set to one represents a valid
Label. The label is the base label plus the position of the bit in Label. The label is the base label plus the position of the bit in
the mask where the bits are numbered left to right beginning with the mask where the bits are numbered left to right beginning with
zero. Label values of all the odd numbers between 1152 and 1279 zero. Label values of all the odd numbers between 1152 and 1279
would be encoded as follows: would be encoded as follows:
skipping to change at page 33, line 36 skipping to change at page 35, line 9
penultimate hop popping. Since the receiving router has no means to penultimate hop popping. Since the receiving router has no means to
differentiate whether the IP packet was sent unlabeled or implicitly differentiate whether the IP packet was sent unlabeled or implicitly
labeled, the addition of labels shimmed above the MPLS echo request labeled, the addition of labels shimmed above the MPLS echo request
(using the Nil FEC) will prevent a router from forwarding such a (using the Nil FEC) will prevent a router from forwarding such a
packet out unlabeled interfaces. packet out unlabeled interfaces.
4.3. Sending an MPLS Echo Request 4.3. Sending an MPLS Echo Request
An MPLS echo request is a UDP packet. The IP header is set as fol- An MPLS echo request is a UDP packet. The IP header is set as fol-
lows: the source IP address is a routable address of the sender; the lows: the source IP address is a routable address of the sender; the
destination IP address is a (randomly chosen) address from 127/8; the destination IP address is a (randomly chosen) IPv4 address from the
IP TTL is set to 1. The source UDP port is chosen by the sender; the range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:127/104.
destination UDP port is set to 3503 (assigned by IANA for MPLS echo the IP TTL is set to 1. The source UDP port is chosen by the sender;
requests). The Router Alert option MUST be set in the IP header. the destination UDP port is set to 3503 (assigned by IANA for MPLS
echo requests). The Router Alert option MUST be set in the IP
header.
An MPlS Echo Request is sent with a label stack corresponding to the An MPlS Echo Request is sent with a label stack corresponding to the
FEC stack being tested. Note that further labels could be applied FEC stack being tested. Note that further labels could be applied
if, for example, the normal route to the topmost FEC in the stack is if, for example, the normal route to the topmost FEC in the stack is
via a Traffic Engineered Tunnel [RSVP-TE]. If all of the FECs in the via a Traffic Engineered Tunnel [RSVP-TE]. If all of the FECs in the
stack correspond to Implicit Null Labels the MPLS echo request is stack correspond to Implicit Null Labels the MPLS echo request is
considered unlabeled even if further labels will be applied in send- considered unlabeled even if further labels will be applied in send-
ing the packet. ing the packet.
If the echo request is labeled, one MAY (depending on what is being If the echo request is labeled, one MAY (depending on what is being
skipping to change at page 37, line 30 skipping to change at page 38, line 48
If the label operation is "Swap or Pop and Switch based on Popped If the label operation is "Swap or Pop and Switch based on Popped
Label" { Label" {
Set Best-return-code to 8 ("Label switched at stack-depth") Set Best-return-code to 8 ("Label switched at stack-depth")
and Best-rtn-subcode to Label-stack-depth to report transit and Best-rtn-subcode to Label-stack-depth to report transit
switching. switching.
If a Downstream Mapping TLV is present in the received Echo If a Downstream Mapping TLV is present in the received Echo
Request { Request {
If the IP address in the TLV is 127.0.0.1 or 0::1: { If the IP address in the TLV is 127.0.0.1 or 0::1 {
Set Best-return-code to 6 ("Upstream Interface Index Set Best-return-code to 6 ("Upstream Interface Index
Unknown"). An Interface and Label Stack TLV SHOULD be Unknown"). An Interface and Label Stack TLV SHOULD be
included in the reply and filled with Interface-I and included in the reply and filled with Interface-I and
Stack-R. Stack-R.
} }
Else { Else {
Verify that the IP address, interface address and label Verify that the IP address, interface address and label
stack in the Downstream Mapping TLV match Interface-I stack in the Downstream Mapping TLV match Interface-I
skipping to change at page 39, line 26 skipping to change at page 40, line 45
Go to step 7 (Send Reply Packet). Go to step 7 (Send Reply Packet).
} }
5. Egress Processing: 5. Egress Processing:
/* These steps are performed by the LSR that identified itself /* These steps are performed by the LSR that identified itself
as the tail-end LSR for an LSP. */ as the tail-end LSR for an LSP. */
If received Echo Request contains no Downstream Mapping TLV, or If received Echo Request contains no Downstream Mapping TLV, or
the Downstream IP Address is set to 127.0.0.1 or 0::1: the Downstream IP Address is set to 127.0.0.1 or 0::1
Go t0 step 6 (Egress FEC Validation). Go t0 step 6 (Egress FEC Validation).
Verify that the IP address, interface address and label stack in Verify that the IP address, interface address and label stack in
the Downstream mapping TLV match Interface-I and Stack-R. If the Downstream mapping TLV match Interface-I and Stack-R. If
not, set Best-return-code to 5, "Downstream Mapping not, set Best-return-code to 5, "Downstream Mapping
Mis-match". A Received Interface and Label Stack TLV SHOULD be Mis-match". A Received Interface and Label Stack TLV SHOULD be
created for the Echo Response packet. Go to step 7 (Send Reply created for the Echo Response packet. Go to step 7 (Send Reply
Packet). Packet).
6. Egress FEC Validation: 6. Egress FEC Validation:
skipping to change at page 44, line 32 skipping to change at page 45, line 49
work-in-progress. work-in-progress.
[RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for [RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
[VCCV] Nadeau, T. & Aggarwal, R., "Pseudo Wire Virtual [VCCV] Nadeau, T. & Aggarwal, R., "Pseudo Wire Virtual
Circuit Connectivity Verification (VCCV), Circuit Connectivity Verification (VCCV),
draft-ietf-pwe3-vccv-07.txt, August 2005, draft-ietf-pwe3-vccv-07.txt, August 2005,
work-in-progress. work-in-progress.
[VPLS] Kompella, K. and Rekhter, Y., "Virtual Private LAN [VPLS-BGP] Kompella, K. and Rekhter, Y., "Virtual Private LAN
Service", draft-ietf-l2vpn-vpls-bgp-05, Service", draft-ietf-l2vpn-vpls-bgp-05,
work-in-progress. work-in-progress.
6. Security Considerations 6. Security Considerations
Overall, the security needs for LSP Ping are are similar to those of Overall, the security needs for LSP Ping are are similar to those of
ICMP Ping. ICMP Ping.
There are at least three approaches to attacking LSRs using the mech- There are at least three approaches to attacking LSRs using the mech-
anisms defined here. One is a Denial of Service attack, by sending anisms defined here. One is a Denial of Service attack, by sending
skipping to change at page 45, line 38 skipping to change at page 47, line 5
the MPLS data plane may be considered confidential by some. Imple- the MPLS data plane may be considered confidential by some. Imple-
mentations SHOULD however provide a means of filtering the addresses mentations SHOULD however provide a means of filtering the addresses
to which Echo Reply messages may be sent. to which Echo Reply messages may be sent.
Although this document makes special use of 127/8 address, these are Although this document makes special use of 127/8 address, these are
used only in conjunction with the UDP port 3503. Further these pack- used only in conjunction with the UDP port 3503. Further these pack-
ets are only processed by routers. All other hosts MUST treat all ets are only processed by routers. All other hosts MUST treat all
packets with a destination address in the range 127/8 in accordance packets with a destination address in the range 127/8 in accordance
to RFC1122. Any packet received by a router with a destination to RFC1122. Any packet received by a router with a destination
address in the range 127/8 without a destination UDP port of 3503 address in the range 127/8 without a destination UDP port of 3503
MUST be treated in accordance to RFC1812. MUST be treated in accordance to RFC1812. In particular, the default
behavior is to treat packets destined to a 127/8 address as "mar-
tians".
7. IANA Considerations 7. IANA Considerations
The TCP and UDP port number 3503 has been allocated by IANA for LSP The TCP and UDP port number 3503 has been allocated by IANA for LSP
echo requests and replies. echo requests and replies.
The following sections detail the new name spaces to be managed by The following sections detail the new name spaces to be managed by
IANA. For each of these name spaces, the space is divided into IANA. For each of these name spaces, the space is divided into
assignment ranges; the following terms are used in describing the assignment ranges; the following terms are used in describing the
procedures by which IANA allocates values: "Standards Action" (as procedures by which IANA allocates values: "Standards Action" (as
skipping to change at page 49, line 28 skipping to change at page 50, line 28
Email: swallow@cisco.com Email: swallow@cisco.com
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Expiration Date Expiration Date
June 2006 July 2006
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 28 change blocks. 
80 lines changed or deleted 149 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/