draft-ietf-mpls-lsp-ping-11.txt   draft-ietf-mpls-lsp-ping-12.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: May 2006 Expiration Date: June 2006
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
November 2005 December 2005
Detecting MPLS Data Plane Failures Detecting MPLS Data Plane Failures
draft-ietf-mpls-lsp-ping-11.txt draft-ietf-mpls-lsp-ping-12.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 7 skipping to change at page 2, line 7
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 Multi-Protocol Label Switching used to detect data plane failures in Multi-Protocol Label Switching
(MPLS) Label Switched Paths (LSPs). There are two parts to this (MPLS) Label Switched Paths (LSPs). There are two parts to this
document: information carried in an MPLS "echo request" and "echo document: information carried in an MPLS "echo request" and "echo
reply" for the purposes of fault detection and isolation; and reply" for the purposes of fault detection and isolation; and
mechanisms for reliably sending the echo reply. mechanisms for reliably sending the echo reply.
Contents Contents
1 Introduction .............................................. 3 1 Introduction .............................................. 4
1.1 Conventions ............................................... 3 1.1 Conventions ............................................... 4
1.2 Structure of this document ................................ 3 1.2 Structure of this document ................................ 4
1.3 Contributors .............................................. 3 1.3 Contributors .............................................. 5
2 Motivation ................................................ 4 2 Motivation ................................................ 5
3 Packet Format ............................................. 5 2.1 Use of address range 127/8 ................................ 6
3.1 Return Codes .............................................. 9 3 Packet Format ............................................. 7
3.2 Target FEC Stack .......................................... 10 3.1 Return Codes .............................................. 12
3.2.1 LDP IPv4 Prefix ........................................... 11 3.2 Target FEC Stack .......................................... 13
3.2.2 LDP IPv6 Prefix ........................................... 11 3.2.1 LDP IPv4 Prefix ........................................... 14
3.2.3 RSVP IPv4 LSP ............................................. 12 3.2.2 LDP IPv6 Prefix ........................................... 14
3.2.4 RSVP IPv6 LSP ............................................. 12 3.2.3 RSVP IPv4 LSP ............................................. 15
3.2.5 VPN IPv4 Prefix ........................................... 13 3.2.4 RSVP IPv6 LSP ............................................. 15
3.2.6 VPN IPv6 Prefix ........................................... 14 3.2.5 VPN IPv4 Prefix ........................................... 16
3.2.7 L2 VPN Endpoint ........................................... 14 3.2.6 VPN IPv6 Prefix ........................................... 17
3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 15 3.2.7 L2 VPN Endpoint ........................................... 17
3.2.9 FEC 128 Pseudowire (Current) .............................. 15 3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 18
3.2.10 FEC 129 Pseudowire ........................................ 16 3.2.9 FEC 128 Pseudowire (Current) .............................. 18
3.2.11 BGP Labeled IPv4 Prefix ................................... 16 3.2.10 FEC 129 Pseudowire ........................................ 19
3.2.12 BGP Labeled IPv6 Prefix ................................... 17 3.2.11 BGP Labeled IPv4 Prefix ................................... 19
3.2.13 Generic IPv4 Prefix ....................................... 17 3.2.12 BGP Labeled IPv6 Prefix ................................... 20
3.2.14 Generic IPv6 Prefix ....................................... 18 3.2.13 Generic IPv4 Prefix ....................................... 20
3.2.15 Nil FEC ................................................... 18 3.2.14 Generic IPv6 Prefix ....................................... 21
3.3 Downstream Mapping ........................................ 19 3.2.15 Nil FEC ................................................... 21
3.3.1 Multipath Information Encoding ............................ 23 3.3 Downstream Mapping ........................................ 22
3.3.2 Downstream Router and Interface ........................... 25 3.3.1 Multipath Information Encoding ............................ 26
3.4 Pad TLV ................................................... 25 3.3.2 Downstream Router and Interface ........................... 28
3.5 Vendor Enterprise Code .................................... 26 3.4 Pad TLV ................................................... 28
3.6 Interface and Label Stack ................................. 26 3.5 Vendor Enterprise Number .................................. 29
3.7 Errored TLVs .............................................. 28 3.6 Interface and Label Stack ................................. 29
3.8 Reply TOS Byte TLV ........................................ 28 3.7 Errored TLVs .............................................. 31
4 Theory of Operation ....................................... 29 3.8 Reply TOS Byte TLV ........................................ 31
4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 29 4 Theory of Operation ....................................... 32
4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 30 4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 32
4.3 Sending an MPLS Echo Request .............................. 30 4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 33
4.4 Receiving an MPLS Echo Request ............................ 31 4.3 Sending an MPLS Echo Request .............................. 33
4.5 Sending an MPLS Echo Reply ................................ 34 4.4 Receiving an MPLS Echo Request ............................ 34
4.6 Receiving an MPLS Echo Reply .............................. 35 4.4.1 FEC Validation ............................................ 40
4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 36 4.5 Sending an MPLS Echo Reply ................................ 41
4.8 Non-compliant Routers ..................................... 36 4.6 Receiving an MPLS Echo Reply .............................. 42
5 References ................................................ 37 4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 42
6 Security Considerations ................................... 38 4.8 Non-compliant Routers ..................................... 43
7 IANA Considerations ....................................... 38 5 References ................................................ 43
7.1 Message Types, Reply Modes, Return Codes .................. 39 6 Security Considerations ................................... 44
7.2 TLVs ...................................................... 40 7 IANA Considerations ....................................... 45
8 Acknowledgments ........................................... 41 7.1 Message Types, Reply Modes, Return Codes .................. 46
7.2 TLVs ...................................................... 47
8 Acknowledgments ........................................... 48
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.
The second part suggests two methods of reliable reply channels for The second part suggests two methods of reliable reply channels for
the echo request message, for more robust fault isolation. the echo request message, for more robust fault isolation.
An important consideration in this design is that MPLS echo requests An important consideration in this design is that MPLS echo requests
follow the same data path that normal MPLS packets would traverse. follow the same data path that normal MPLS packets would traverse.
MPLS echo requests are meant primarily to validate the data plane, MPLS echo requests are meant primarily to validate the data plane,
and secondarily to verify the data plane against the control plane. and secondarily to verify the data plane against the control plane.
Mechanisms to check the control plane are valuable, but are not cov- Mechanisms to check the control plane are valuable, but are not cov-
ered in this document. ered in this document.
This document makes special use of the address range 127/8. This is
an exception to the behavior defined in RFC1122 [RFC1122] and updates
that RFC. The motivation for this change and the details of this
exceptional use are discussed in section 2.1 below.
1.1. Conventions 1.1. Conventions
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 RFC 2119 [KEYWORDS]. document are to be interpreted as described in RFC 2119 [KEYWORDS].
The term "Must be Zero" (MBZ) is used in object decriptions for The term "Must be Zero" (MBZ) is used in object descriptions for
reserved fields. These fields MUST be set to zero when sent and reserved fields. These fields MUST be set to zero when sent and
ignored on receipt. ignored on receipt.
Terminology pertaining to L2 and L3 VPNs is defined in [RFC4026].
1.2. Structure of this document 1.2. Structure of this document
The body of this memo contains four main parts: motivation, MPLS echo The body of this memo contains four main parts: motivation, MPLS echo
request/reply packet format, LSP ping operation, and a reliable request/reply packet format, LSP ping operation, and a reliable
return path. It is suggested that first-time readers skip the actual return path. It is suggested that first-time readers skip the actual
packet formats and read the Theory of Operation first; the document packet formats and read the Theory of Operation first; the document
is structured the way it is to avoid forward references. is structured the way it is to avoid forward references.
1.3. Contributors 1.3. Contributors
skipping to change at page 5, line 5 skipping to change at page 6, line 9
the control plane against the data plane, i.e., that forwarding the control plane against the data plane, i.e., that forwarding
matches what the routing protocols determined as the path. matches what the routing protocols determined as the path.
One way these tools can be used is to periodically ping a FEC to One way these tools can be used is to periodically ping a FEC to
ensure connectivity. If the ping fails, one can then initiate a ensure connectivity. If the ping fails, one can then initiate a
traceroute to determine where the fault lies. One can also periodi- traceroute to determine where the fault lies. One can also periodi-
cally traceroute FECs to verify that forwarding matches the control cally traceroute FECs to verify that forwarding matches the control
plane; however, this places a greater burden on transit LSRs and thus plane; however, this places a greater burden on transit LSRs and thus
should be used with caution. should be used with caution.
2.1. Use of address range 127/8
As described above, LSP Ping is intended as a diagnostic tool. It is
intended to enable providers of an MPLS based service to isolate net-
work faults. In particular LSP Ping needs to diagnose situations
where the control and data planes are out of sync. It performs this
by routing an MPLS echo request packet based solely on its label
stack. That is the IP destination address is never used in a for-
warding decision. In fact, the sender of an MPLS echo request packet
may not know, a priori, the address of the router at the end of the
LSP.
Providers of MPLS based services also need the ability to trace all
of the possible paths that an LSP make take. Since most MPLS ser-
vices are based on IP unicast forwarding, these paths are subject to
equal cost multi-path load sharing (ECMP).
This leads to the following requirements:
1. Although the LSP in question may be broken in unknown ways, the
likelihood of a diagnostic packet being delivered to a user of an
MPLS service MUST be held to an absolute minimum.
2. If an LSP is broken in such a way that it prematurely terminates,
the diagnostic packet MUST NOT be IP forwarded.
3. A means of varying the diagnostic packets such that they exercise
all ECMP paths is thus REQUIRED.
Clearly using general unicast addresses satisfies neither of the
first two requirements. A number of other options for addresses were
considered, including a portion of the private address space (as
determined by the network operator) and the newly designated IPv4
link local addresses. Use of the private address space was deemed
ineffective since the leading MPLS based service is IPv4 Virtual Pri-
vate Networks (VPN). VPNs often used private addresses.
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
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
have that addressed assigned to the interface on which it arrived and
thus could mistakenly receive such a packet. Further, the IPv4 link
local address range has only recently been allocated. Many deployed
routers would forward a packet with an address from that range toward
the default route.
The 127/8 range for IPv4 and that same range embedded in an IPv6
addresses for IPv6 was chosen for a number of reasons.
RFC1122 allocates the 127/8 as "Internal host loopback address" and
states that "Addresses of this form MUST NOT appear outside a host."
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
host, it will be silently discarded.
RFC1812 [RFC1812] states that:
A router SHOULD NOT forward, except over a loopback interface, any
packet that has a destination address on network 127. A router
MAY have a switch that allows the network manager to disable these
checks. If such a switch is provided, it MUST default to perform-
ing the checks.
This helps to ensure that diagnostic packets are never IP forwarded.
The 127/8 address range provides 16M addresses allowing wide flexi-
bility in varying addresses to exercise ECMP paths. Finally, as an
implementation optimization, the 127/8 provides an easy means of
identifying possible LSP Packets.
3. Packet Format 3. Packet Format
An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet; An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet;
the contents of the UDP packet have the following format: the contents of the UDP packet have the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags | | Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 39 skipping to change at page 9, line 34
log gaps in the sequence numbers and/or maintain delay/jitter statis- log gaps in the sequence numbers and/or maintain delay/jitter statis-
tics. An MPLS echo request would normally have 2 (Reply via an tics. An MPLS echo request would normally have 2 (Reply via an
IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP
return path is deemed unreliable, one may use 3 (Reply via an return path is deemed unreliable, one may use 3 (Reply via an
IPv4/IPv6 UDP packet with Router Alert). Note that this requires IPv4/IPv6 UDP packet with Router Alert). Note that this requires
that all intermediate routers understand and know how to forward MPLS that all intermediate routers understand and know how to forward MPLS
echo replies. The echo reply uses the same IP version number as the echo replies. The echo reply uses the same IP version number as the
received echo request, i.e., an IPv4 encapsulated echo reply is sent received echo request, i.e., an IPv4 encapsulated echo reply is sent
in response to an IPv4 encapsulated echo request. in response to an IPv4 encapsulated echo request.
Any application which supports an IP control channel between its con- Some applications support an IP control channel. One such example is
trol entities may set the Reply Mode to 4 (Reply via application the associated control channel defined in Virtual Circuit Connectiv-
level control channel) to ensure that replies use that same channel. ity Verification [VCCV]. Any application which supports an IP con-
Further definition of this codepoint is application specific and thus trol channel between its control entities may set the Reply Mode to 4
beyond the scope of this document. (Reply via application level control channel) to ensure that replies
use that same channel. Further definition of this codepoint is
application specific and thus beyond the scope of this document.
Return Codes and Subcodes are described in the next section. Return Codes and Subcodes are described in the next section.
the Sender's Handle is filled in by the sender, and returned the Sender's Handle is filled in by the sender, and returned
unchanged by the receiver in the echo reply (if any). There are no unchanged by the receiver in the echo reply (if any). There are no
semantics associated with this handle, although a sender may find semantics associated with this handle, although a sender may find
this useful for matching up requests with replies. this useful for matching up requests with replies.
The Sequence Number is assigned by the sender of the MPLS echo The Sequence Number is assigned by the sender of the MPLS echo
request, and can be (for example) used to detect missed replies. request, and can be (for example) used to detect missed replies.
The TimeStamp Sent is the time-of-day (in seconds and microseconds, The TimeStamp Sent is the time-of-day (in seconds and microseconds,
according to the sender's clock) when the MPLS echo request is sent. according to the sender's clock) in NTP format [NTP] when the MPLS
The TimeStamp Received in an echo reply is the time-of-day (according echo request is sent. The TimeStamp Received in an echo reply is the
to the receiver's clock) that the corresponding echo request was time-of-day (according to the receiver's clock) in NTP format that
received. the corresponding echo request was received.
TLVs (Type-Length-Value tuples) have the following format: TLVs (Type-Length-Value tuples) have the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
. . . .
skipping to change at page 8, line 35 skipping to change at page 11, line 35
A description of the Types and Values of the top level TLVs for LSP A description of the Types and Values of the top level TLVs for LSP
ping are given below: ping are given below:
Type # Value Field Type # Value Field
------ ----------- ------ -----------
1 Target FEC Stack 1 Target FEC Stack
2 Downstream Mapping 2 Downstream Mapping
3 Pad 3 Pad
4 Not Assigned 4 Not Assigned
5 Vendor Enterprise Code 5 Vendor Enterprise Number
6 Not Assigned 6 Not Assigned
7 Interface and Label Stack 7 Interface and Label Stack
8 Not Assigned 8 Not Assigned
9 Errored TLVs 9 Errored TLVs
10 Reply TOS Byte 10 Reply TOS Byte
Types less than 32768 (i.e., with the high order bit equal to 0) are Types less than 32768 (i.e., with the high order bit equal to 0) are
mandatory TLVs that MUST either be supported by an implementation or mandatory TLVs that MUST either be supported by an implementation or
result in the return code of 2 ("One or more of the TLVs was not result in the return code of 2 ("One or more of the TLVs was not
understood") being sent in the echo response. understood") being sent in the echo response.
skipping to change at page 14, line 34 skipping to change at page 17, line 34
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 BGP NLRI and VE ID are defined in [VPLS]. This document uses
the simpler term L2 VPN endpoint when refering to a VPLS BGP NLRI. the simpler term L2 VPN endpoint when referring to a VPLS BGP NLRI.
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 |
skipping to change at page 16, line 26 skipping to change at page 19, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~ ~ AGI Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | Value | | AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~ ~ SAII Value (continued) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | Value | | AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~ ~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.)| 0-3 octets of zero padding | | TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.11. BGP Labeled IPv4 Prefix 3.2.11. BGP Labeled IPv4 Prefix
BGP labeled IPv4 prefixes are defined in [BGP-LABEL]. When a BGP BGP labeled IPv4 prefixes are defined in [BGP-LABEL]. When a BGP
labeled IPv4 prefix is encoded in a label stack, the following format labeled IPv4 prefix is encoded in a label stack, the following format
is used. The value field consists the IPv4 prefix (with trailing 0 is used. The value field consists the IPv4 prefix (with trailing 0
bits to make 32 bits in all), and the prefix length, as follows: bits to make 32 bits in all), and the prefix length, as follows:
0 1 2 3 0 1 2 3
skipping to change at page 23, line 13 skipping to change at page 26, line 13
the next section below for encoding details. the next section below for encoding details.
Downstream Label(s) Downstream Label(s)
The set of labels in the label stack as it would have appeared if The set of labels in the label stack as it would have appeared if
this router were forwarding the packet through this interface. Any this router were forwarding the packet through this interface. Any
Implicit Null labels are explicitly included. Labels are treated as Implicit Null labels are explicitly included. Labels are treated as
numbers, i.e. they are right justified in the field. numbers, i.e. they are right justified in the field.
A Downstream Label is 24 bits, in the same format as an MPLS label A Downstream Label is 24 bits, in the same format as an MPLS label
minus the TTL field, i.e., the MSBit of the label is bit 0, the LSbit minus the TTL field, i.e., the MSBit of the label is bit 0, the LSBit
is bit 19, the EXP bits are bits 20-22, and bit 23 is the S bit. The is bit 19, the EXP bits are bits 20-22, and bit 23 is the S bit. The
replying router SHOULD fill in the EXP and S bits; the LSR receiving replying router SHOULD fill in the EXP and S bits; the LSR receiving
the echo reply MAY choose to ignore these bits. the echo reply MAY choose to ignore these bits.
Protocol Protocol
The Protocol is taken from the following table: The Protocol is taken from the following table:
Protocol # Signaling Protocol Protocol # Signaling Protocol
---------- ------------------ ---------- ------------------
skipping to change at page 26, line 11 skipping to change at page 29, line 11
the other octets (if any) are ignored. The receiver SHOULD verify the other octets (if any) are ignored. The receiver SHOULD verify
that the TLV is received in its entirety, but otherwise ignores the that the TLV is received in its entirety, but otherwise ignores the
contents of this TLV, apart from the first octet. contents of this TLV, apart from the first octet.
Value Meaning Value Meaning
----- ------- ----- -------
1 Drop Pad TLV from reply 1 Drop Pad TLV from reply
2 Copy Pad TLV to reply 2 Copy Pad TLV to reply
3-255 Reserved for future use 3-255 Reserved for future use
3.5. Vendor Enterprise Code 3.5. Vendor Enterprise Number
The Length is always 4; the value is the SMI Enterprise code, in net- SMI Private Enterprise Numbers are maintained by IANA. The Length is
work octet order, of the vendor with a Vendor Private extension to always 4; the value is the SMI Private Enterprise code, in network
any of the fields in the fixed part of the message, in which case octet order, of the vendor with a Vendor Private extension to any of
this TLV MUST be present. If none of the fields in the fixed part of the fields in the fixed part of the message, in which case this TLV
the message have vendor private extensions, inclusion of this this MUST be present. If none of the fields in the fixed part of the mes-
TLV in is OPTIONAL. Vendor private ranges for Message Types, Reply sage have vendor private extensions, inclusion of this this TLV in is
Modes, and Return Codes have been defined. When any of these are OPTIONAL. Vendor private ranges for Message Types, Reply Modes, and
used the Vendor Enterprise Code TLV MUST be included in the message. Return Codes have been defined. When any of these are used the Ven-
dor Enterprise Number TLV MUST be included in the message.
3.6. Interface and Label Stack 3.6. Interface and Label Stack
The Interface and Label Stack TLV MAY be included in a reply message The Interface and Label Stack TLV MAY be included in a reply message
to report the interface on which the request message was received and to report the interface on which the request message was received and
the label stack which was on the packet when it was received. Only the label stack which was on the packet when it was received. Only
one such object may appear. The purpose of the object is to allow one such object may appear. The purpose of the object is to allow
the upstream router to obtain the exact interface and label stack the upstream router to obtain the exact interface and label stack
information as it appears at the replying LSR. information as it appears at the replying LSR.
skipping to change at page 30, line 34 skipping to change at page 33, line 34
the LSP ping may forward the MPLS echo request successfully over an the LSP ping may forward the MPLS echo request successfully over an
interface not configured to carry MPLS payloads because of the use of interface not configured to carry MPLS payloads because of the use of
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 (possibly) labeled UDP packet. The IP An MPLS echo request is a UDP packet. The IP header is set as fol-
header is set as follows: the source IP address is a routable address lows: the source IP address is a routable address of the sender; the
of the sender; the destination IP address is a (randomly chosen) destination IP address is a (randomly chosen) address from 127/8; the
address from 127/8; the IP TTL is set to 1. The source UDP port is IP TTL is set to 1. The source UDP port is chosen by the sender; the
chosen by the sender; the destination UDP port is set to 3503 destination UDP port is set to 3503 (assigned by IANA for MPLS echo
(assigned by IANA for MPLS echo requests). The Router Alert option requests). The Router Alert option MUST be set in the IP header.
is set in the IP header.
If the echo request is labeled, one may (depending on what is being An MPlS Echo Request is sent with a label stack corresponding to the
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
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
considered unlabeled even if further labels will be applied in send-
ing the packet.
If the echo request is labeled, one MAY (depending on what is being
pinged) set the TTL of the innermost label to 1, to prevent the ping pinged) set the TTL of the innermost label to 1, to prevent the ping
request going farther than it should. Examples of this include ping- request going farther than it should. Examples of where this SHOULD
ing a VPN IPv4 or IPv6 prefix, an L2 VPN end point or a pseudowire. be done include pinging a VPN IPv4 or IPv6 prefix, an L2 VPN end
This can also be accomplished by inserting a router alert label above point or a pseudowire. Preventing the ping request from going to far
this label; however, this may lead to the undesired side effect that can also be accomplished by inserting a router alert label above this
MPLS echo requests take a different data path than actual data. label; however, this may lead to the undesired side effect that MPLS
echo requests take a different data path than actual data. For more
information on how these mechanisms can be used for pseudowire con-
nectivity verification, see [VCCV].
In "ping" mode (end-to-end connectivity check), the TTL in the outer- In "ping" mode (end-to-end connectivity check), the TTL in the outer-
most label is set to 255. In "traceroute" mode (fault isolation most label is set to 255. In "traceroute" mode (fault isolation
mode), the TTL is set successively to 1, 2, .... mode), the TTL is set successively to 1, 2, ....
The sender chooses a Sender's Handle, and a Sequence Number. When The sender chooses a Sender's Handle, and a Sequence Number. When
sending subsequent MPLS echo requests, the sender SHOULD increment sending subsequent MPLS echo requests, the sender SHOULD increment
the sequence number by 1. However, a sender MAY choose to send a the sequence number by 1. However, a sender MAY choose to send a
group of echo requests with the same sequence number to improve the group of echo requests with the same sequence number to improve the
chance of arrival of at least one packet with that sequence number. chance of arrival of at least one packet with that sequence number.
skipping to change at page 31, line 26 skipping to change at page 34, line 35
microseconds) that the echo request is sent. The TimeStamp Received microseconds) that the echo request is sent. The TimeStamp Received
is set to zero. is set to zero.
An MPLS echo request MUST have a FEC Stack TLV. Also, the Reply Mode An MPLS echo request MUST have a FEC Stack TLV. Also, the Reply Mode
must be set to the desired reply mode; the Return Code and Subcode must be set to the desired reply mode; the Return Code and Subcode
are set to zero. In the "traceroute" mode, the echo request SHOULD are set to zero. In the "traceroute" mode, the echo request SHOULD
include a Downstream Mapping TLV. include a Downstream Mapping TLV.
4.4. Receiving an MPLS Echo Request 4.4. Receiving an MPLS Echo Request
An LSR X that receives an MPLS echo request first parses the packet Sending An MPLS Echo Request to the control plane is triggered by
to ensure that it is a well-formed packet, and that the TLVs that are one of the following packet processing exceptions: Router Alert
not marked "Ignore" are understood. If not, X SHOULD send an MPLS Option, IP TTL expiration, MPLS TTL expiration, MPLS Router Alert
echo reply with the Return Code set to "Malformed echo request Label, or the destination address in the 127/8 address range. The
received" or "TLV not understood" (as appropriate), and the Subcode control plane further identifies it by UDP destination port 3503.
set to zero. In the latter case, the misunderstood TLVs (only) are
included in the reply.
If the echo request is good, X notes the interface I over which the For reporting purposes the bottom of stack is considered to be
echo was received, and the label stack with which it came. stack-depth of 1. This is to establish an absolute reference for
the case where the actual stack may have more labels than there are
FECs in the Target FEC Stack.
For reporting purposes the bottom of stack is considered to be stack- Further, in all the error codes listed in this document a
depth of 1. This is to establish an absolute reference for the case stack-depth of 0 means "no value specified". This allows
where the stack may have more labels than are in the FEC stack. Fur- compatibility with existing implementations which do not use the
ther, in all the error codes listed in this document a stack-depth of Return Subcode field.
0 means "no value specified". This allows compatibility with exist-
ing implementations which do not use the Return Subcode field.
X employs two variables, called FEC-stack-depth and Label-stack- An LSR X that receives an MPLS Echo Request then processes it as
depth. X sets Label-stack-depth to the number of labels in the follows.
received label stack. If the label-stack-depth is 0, assume there is
one implicit null label and set label-stack-depth to 1. FEC-stack-
depth is used later and need not be initialized. Processing now con-
tinues with the following steps:
Label_Validation: 1. General packet sanity is verified. If the packet is not
well-formed, LSR X SHOULD send an MPLS Echo Reply with the
Return Code set to "Malformed echo request received" and the
Subcode to zero. If there are any TLVs not marked as "Ignore"
that LSR X does not understand, LSR X SHOULD send an MPLS "TLV
not understood" (as appropriate), and the Subcode set to
zero. In the latter case, the misunderstood TLVs (only) are
included as sub-TLVs in an Errored TLVs TLV in the reply. The
header fields Sender's Handle, Sequence Number, and Timestamp
Sent are not examined, but are included in the MPLS Echo Reply
message.
If the label at Label-stack-depth is valid, goto Label_Operation. The algorithm uses the following variables and identifiers:
If not, set Best-return-code to 11, "No label entry at stack-depth"
and Best-return-subcode to Label-stack-depth. Goto
Send_Reply_Packet.
Label_Operation: Interface-I: the interface on which the MPLS Echo Request was
received.
Switch on label operation. Stack-R: the label stack on the packet as it was
received.
Case: Pop and Continue Processing (Note: this includes Stack-D: the label stack carried in the Downstream
Explicit_Null and Router_Alert) Mapping TLV (not always present)
If Label-stack-depth is greater than 1, decrement Label-stack- Label-L: the label from the actual stack currently being
depth and goto Label_Validation. Otherwise, set FEC-stack-depth examined. Requires no initialization.
to 1, set Best-return-code to 3 "Replying router is an egress for
the FEC at stack depth", set Best-return-subcode to 1 and goto
Egress_Processing.
Case: Swap or Pop and Switch based on Popped Label Label-stack-depth: the depth of label being verified. Initialized
to the number of labels in the received label
stack S.
If the label operation is either swap or pop and switch based on FEC-stack-depth: depth of the FEC in the Target FEC Stack that
the popped label, Best-return-code to 8, "Label switched at should be used to verify the current actual
stack-depth" and Best-return-subcode to Label-stack-depth. label. Requires no initialization.
If a Downstream Mapping TLV is present, a Downstream mapping TLVs Best-return-code: contains the return code for the Echo Reply
SHOULD be created for each multipath. packet as currently best known. As algorithm
progresses, this code may change depending on
the results of further checks that it performs.
Determine the output interface. If it is not valid to forward a Best-rtn-subcode: similar to Best-return-code, but for the Echo
labeled packet on this interface, set Best-return-code to Return Reply Subcode.
Code 9, "Label switched but no MPLS forwarding at stack-depth"
and set Best-return-subcode to Label-stack-depth and goto
Send_Reply_Packet. (Note: this return code is set even if Label-
stack-depth is one.)
If no Downstream Mapping TLV is present, or the Downstream IP FEC-status: result value returned by the FEC Checking
Address is set to the All-Routers multicast address goto algorithm described in section 4.4.1.
Send_Reply_Packet.
Verify that the IP address, interface address and label stack /* Save receive context information */
match the received interface and label stack. If the IP address
is either 127.0.0.1 or 0::1 bypass the interface check, and set
Best-return-code to 6, "Upstream Interface Index Unknown". For
any other error, set Best-return-code to 5, "Downstream Mapping
Mis-match". For either error, an Interface and Label Stack TLV
SHOULD be created. If Best-return-code equals 5, goto
Send_Reply_Packet.
If the "Validate FEC Stack" flag is not set, goto 2. If the echo request is good, LSR X stores the interface over
Send_Reply_Packet. which the echo was received in Interface-I, and the label stack
with which it came in Stack-R.
Locate the label at Label-stack-depth in the Downstream Labels by /* The rest of the algorithm iterates over the labels in Stack-R,
counting from the bottom of the stack, skipping over, but count- verifies validity of label values, reports associated label
ing Implicit Null labels and set FEC-stack-depth to that depth. switching operations (for traceroute), verifies correspondence
(Note: If the Downstream Labels contain one or more Implicit Null between the Stack-R and the Target FEC Stack description in the
labels, this may be at a depth greater than Label-stack-depth.) body of the Echo Request, and reports any errors. */
If the depth of the FEC stack is greater than or equal to FEC- /* The algorithm iterates as follows. */
stack-depth, Perform FEC Checking. If FEC-status is 2, set Best-
return-code to 10, "Mapping for this FEC is not the given label
at stack-depth".
If the return code is 1 set Best-return-code to FEC-return-code 3. Label Validation:
and Best-return-subcode to FEC-stack-depth.
Goto Send_Reply_Packet. If Label-stack-depth is 0 {
Egress_Processing: /* The LSR needs to report its being a tail-end for the LSP */
If no Downstream Mapping TLV is present, goto Egress_FEC_Valida- Set FEC-stack-depth to 1, set Label-L to 3 (Implicit Null).
tion. Set Best-return-code to 3 ("Replying router is an egress for
the FEC at stack depth"), set Best-rtn-subcode to the
value of FEC-stack-depth (1) and go to step 5 (Egress
Processing).
}
Verify that the IP address, interface address and label stack match /* This step assumes there's always an entry for well-known
the received interface and label stack. If not, set Best-return- label values */
code to 5, "Downstream Mapping Mis-match". A Received Interface
and Label Stack TLV SHOULD be created. Goto Send_Reply_Packet.
Egress_FEC_Validation: Set Label-L to the value extracted from Stack-R at depth
Label-stack-depth. Lookup Label-L in the Incoming Label Map
(ILM) to determine if the label has been allocated and an
operation is associated with it.
Perform FEC checking. If FEC-status is 1, set Best-return-code If there is no entry for L {
to FEC-code and Best-return-subcode to FEC-stack-depth. Goto
/* Indicates a temporary or permanent label synchronization
problem the LSR needs to report an error */
Set Best-return-code to 11 ("No label entry at stack-depth")
and Best-rtn-subcode to Label-stack-depth. Go to step 7
(Send Reply Packet).
}
Else {
Retrieve the associated label operation from the
corresponding NLFE and proceed to step 4 (Label Operation).
}
4. Label Operation Check
If the label operation is "Pop and Continue Processing" {
/* Includes Explicit Null and Router Alert label cases */
Iterate to the next label by decrementing Label-stack-depth
and loop back to step 3 (Label Validation).
}
If the label operation is "Swap or Pop and Switch based on Popped
Label" {
Set Best-return-code to 8 ("Label switched at stack-depth")
and Best-rtn-subcode to Label-stack-depth to report transit
switching.
If a Downstream Mapping TLV is present in the received Echo
Request {
If the IP address in the TLV is 127.0.0.1 or 0::1: {
Set Best-return-code to 6 ("Upstream Interface Index
Unknown"). An Interface and Label Stack TLV SHOULD be
included in the reply and filled with Interface-I and
Stack-R.
}
Else {
Verify that the IP address, interface address and label
stack in the Downstream Mapping TLV match Interface-I
and Stack-R. If there is a mismatch, set
Best-return-code to 5, "Downstream Mapping Mismatch".
An Interface and Label Stack TLV SHOULD be included in
the reply and filled in based on Interface-I and
Stack-R. Go to step 7 (Send Reply Packet).
}
}
For each available downstream ECMP path {
Retrieve output interface from the NHLFE entry.
/* Note: this return code is set even if Label-stack-depth
is one */
If the output interface is not MPLS-enabled {
set Best-return-code to Return Code 9, "Label switched
but no MPLS forwarding at stack-depth" and set
Best-rtn-subcode to Label-stack-depth and goto
Send_Reply_Packet. Send_Reply_Packet.
}
Increment FEC-stack-depth. If FEC-stack-depth is greater than If a Downstream Mapping TLV is present {
the number of FECs in the FEC-stack, goto Send_Reply_Packet. If
FEC-status is 0, increment Label-stack-depth. Goto
Egress_FEC_Validation.
Send_Reply_Packet: A Downstream mapping TLV SHOULD be included in the Echo
Reply (see section 3.3) filled in with information about
the current ECMP path.
}
}
Send an MPLS echo reply with a Return Code of Best-return-code, If no Downstream Mapping TLV is present, or the Downstream IP
and a Return Subcode of Best-return-subcode. Include any TLVs Address is set to the ALLROUTERS multicast address,
created during the above process. The procedures for sending the Go to step 7 (Send Reply Packet).
echo reply are found in the next subsection below.
FEC_Checking: If the "Validate FEC Stack" flag is not set and the LSR is not
configured to perform FEC checking by default, go to step 7
(Send Reply Packet).
This routine accepts a FEC, Label, and Interface. It returns two /* Validate the Target FEC Stack in the received Echo Request.
values, FEC-status and FEC-return-code, both of which are First determine FEC-stack-depth from the Downstream Mapping
initialized to 0. TLV. This is done by walking through Stack-D (the Downstream
Labels) from the bottom, decrementing the number of labels
for each non-Implicit Null label, while incrementing
FEC-stack-depth for each label. If the Downstream Mapping TLV
contains one or more Implicit Null labels, FEC-stack-depth
may be greater than Label-stack-depth. To be consistent with
the above stack-depths, the bottom is considered to entry 1.
*/
If the FEC is the Nil FEC, check that Label is either Set FEC-stack-depth to 0. Set i to Label-stack-depth.
Explicit_Null or Router_Alert. If so return. Else
set FEC-return-code to 10, "Mapping for this FEC is not the given
label at stack-depth". Set FEC-status to 1 and return.
Check that the label mapping for FEC. If no mapping exists, set While (i > 0 ) do {
FEC-return-code to Return 4, "Replying router has no mapping for ++FEC-stack-depth.
the FEC at stack-depth". Set FEC-status to 1. Return. if Stack-D[FEC-stack-depth] != 3 (Implicit Null)
--i.
}
If the number of labels in the FEC stack is greater
than or equal to FEC-stack-depth {
If the label mapping for FEC is Implicit Null, set FEC-status to Perform the FEC Checking procedure (see subsection 4.4.1
2. Goto Check_Protocol. below).
If the label mapping for FEC is Label, goto Check_Protocol. Else If FEC-status is 2 set Best-return-code to 10 ("Mapping
set FEC-return-code to 10, "Mapping for this FEC is not the given for this FEC is not the given label at stack-depth").
label at stack-depth". Set FEC-status to 1 and return.
Check_Protocol: If the return code is 1 set Best-return-code to
FEC-return-code and Best-rtn-subcode to FEC-stack-depth.
}
Check what protocol would be used to advertise FEC. If it can be Go to step 7 (Send Reply Packet).
determined that no protocol associated with interface I would }
have advertised a FEC of that FEC-Type, set FEC-return-code to
12, "Protocol not associated with interface at FEC stack-depth". 5. Egress Processing:
Set FEC-status to 1. Return.
/* These steps are performed by the LSR that identified itself
as the tail-end LSR for an LSP. */
If received Echo Request contains no Downstream Mapping TLV, or
the Downstream IP Address is set to 127.0.0.1 or 0::1:
Go t0 step 6 (Egress FEC Validation).
Verify that the IP address, interface address and label stack in
the Downstream mapping TLV match Interface-I and Stack-R. If
not, set Best-return-code to 5, "Downstream Mapping
Mis-match". A Received Interface and Label Stack TLV SHOULD be
created for the Echo Response packet. Go to step 7 (Send Reply
Packet).
6. Egress FEC Validation:
/* This is a loop for all entries in the Target FEC Stack
starting with FEC-stack-depth. */
Perform FEC checking by following the algorithm described in
subsection 4.4.1 for Label-L and the FEC at FEC-stack-depth.
Set Best-return-code to FEC-code and Best-rtn-subcode to the
value in FEC-stack-depth.
If FEC-status (the result of the check) is 1,
Go to step 7 (Send Reply Packet).
/* Iterate to the next FEC entry */
++FEC-stack-depth.
If FEC-stack-depth > the number of FECs in the FEC-stack,
Go to step 7 (Send Reply Packet).
If FEC-status is 0 {
++Label-stack-depth.
If Label-stack-depth > the number of labels in Stack-R,
Go to step 7 (Send Reply Packet).
Label-L = extracted label from Stack-R at depth
Label-stack-depth.
Loop back to step 6 (Egress FEC Validation).
}
7. Send Reply Packet:
Send an MPLS Echo Reply with a Return Code of Best-return-code,
and a Return Subcode of Best-rtn-subcode. Include any TLVs
created during the above process. The procedures for sending
the Echo Reply are found in subsection 4.4.1.
4.4.1. FEC Validation
/* This subsection describes validation of a FEC entry within the
Target FEC Stack and accepts a FEC, Label-L and Interface-I.
The algorithm performs the following steps. */
1. Two return values, FEC-status and FEC-return-code, are initialized
to 0.
2. If the FEC is the Nil FEC {
If Label-L is either Explicit_Null or Router_Alert, return.
Else {
Set FEC-return-code to 10 ("Mapping for this FEC is not
the given label at stack-depth").
Set FEC-status to 1
Return.
}
}
3. Check the FEC label mapping that describes how traffic received
on the LSP is further switched or which application it is
associated with. If no mapping exists, set FEC-return-code to
Return 4, "Replying router has no mapping for the FEC at
stack-depth". Set FEC-status to 1. Return.
4. If the label mapping for FEC is Implicit Null, set FEC-status to
2 and proceed to step 5. Otherwise, if the label mapping for FEC
is Label-L, proceed to step 5. Otherwise, set FEC-return-code to
10 ("Mapping for this FEC is not the given label at
stack-depth"), set FEC-status to 1 and return.
5. This is a protocol check. Check what protocol would be used to
advertise FEC. If it can be determined that no protocol
associated with Interface-I would have advertised a FEC of that
FEC-Type, set FEC-return-code to 12 ("Protocol not associated
with interface at FEC stack-depth"). Set FEC-status to 1.
6. Return.
4.5. Sending an MPLS Echo Reply 4.5. Sending an MPLS Echo Reply
An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response
to an MPLS echo request. The source IP address is a routable address to an MPLS echo request. The source IP address is a routable address
of the replier; the source port is the well-known UDP port for LSP of the replier; the source port is the well-known UDP port for LSP
ping. The destination IP address and UDP port are copied from the ping. The destination IP address and UDP port are copied from the
source IP address and UDP port of the echo request. The IP TTL is source IP address and UDP port of the echo request. The IP TTL is
set to 255. If the Reply Mode in the echo request is "Reply via an set to 255. If the Reply Mode in the echo request is "Reply via an
IPv4 UDP packet with Router Alert", then the IP header MUST contain IPv4 UDP packet with Router Alert", then the IP header MUST contain
skipping to change at page 35, line 36 skipping to change at page 42, line 14
label, and add Downstream Mapping TLVs for each one to the echo reply label, and add Downstream Mapping TLVs for each one to the echo reply
it sends back. it sends back.
If the Downstream Mapping TLV contains multipath information requir- If the Downstream Mapping TLV contains multipath information requir-
ing more processing than the receiving router is willing to perform, ing more processing than the receiving router is willing to perform,
the responding router MAY choose to respond with only a subset of the responding router MAY choose to respond with only a subset of
multipaths contained in the echo request Downstream Map. (Note: The multipaths contained in the echo request Downstream Map. (Note: The
originator of the echo request MAY send another echo request with the originator of the echo request MAY send another echo request with the
multipath information that was not included in the reply.) multipath information that was not included in the reply.)
Except in the case of Reply Mode 4, "Reply via application level con-
trol channel", Echo Replies are always sent in the context of the
IP/MPLS network.
4.6. Receiving an MPLS Echo Reply 4.6. Receiving an MPLS Echo Reply
An LSR X should only receive an MPLS echo reply in response to an An LSR X should only receive an MPLS echo reply in response to an
MPLS echo request that it sent. Thus, on receipt of an MPLS echo MPLS echo request that it sent. Thus, on receipt of an MPLS echo
reply, X should parse the packet to assure that it is well-formed, reply, X should parse the packet to assure that it is well-formed,
then attempt to match up the echo reply with an echo request that it then attempt to match up the echo reply with an echo request that it
had previously sent, using the destination UDP port and the Sender's had previously sent, using the destination UDP port and the Sender's
Handle. If no match is found, then X jettisons the echo reply; oth- Handle. If no match is found, then X jettisons the echo reply; oth-
erwise, it checks the Sequence Number to see if it matches. Gaps in erwise, it checks the Sequence Number to see if it matches.
the Sequence Number MAY be logged and SHOULD be counted. Once an
echo reply is received for a given Sequence Number (for a given UDP
port and Handle), the Sequence Number for subsequent echo requests
for that UDP port and Handle SHOULD be incremented.
If the echo reply contains Downstream Mappings, and X wishes to If the echo reply contains Downstream Mappings, and X wishes to
traceroute further, it SHOULD copy the Downstream Mapping(s) into its traceroute further, it SHOULD copy the Downstream Mapping(s) into its
next echo request(s) (with TTL incremented by one). next echo request(s) (with TTL incremented by one).
4.7. Issue with VPN IPv4 and IPv6 Prefixes 4.7. Issue with VPN IPv4 and IPv6 Prefixes
Typically, a LSP ping for a VPN IPv4 prefix or VPN IPv6 prefix is Typically, a LSP ping for a VPN IPv4 prefix or VPN IPv6 prefix is
sent with a label stack of depth greater than 1, with the innermost sent with a label stack of depth greater than 1, with the innermost
label having a TTL of 1. This is to terminate the ping at the egress label having a TTL of 1. This is to terminate the ping at the egress
skipping to change at page 37, line 21 skipping to change at page 43, line 37
[IANA] Narten, T. and H. Alvestrand, "Guidelines for IANA [IANA] Narten, T. and H. Alvestrand, "Guidelines for IANA
Considerations", BCP 26, RFC 2434, October 1998. Considerations", BCP 26, RFC 2434, October 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] 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.
[LABEL-STACK] Rosen, E., et al, "MPLS Label Stack Encoding", [LABEL-STACK] Rosen, E., et al, "MPLS Label Stack Encoding",
RFC 3032, January 2001. RFC 3032, January 2001.
[NTP] Mills, D., "Simple Network Time Protocol (SNTP)
Version 4 for IPv4, IPv6 and OSI", RFC 2030, October
1996.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Almquist, P. and F. Kastenholz, "Towards Requirements
for IP Routers", RFC 1716, November 1994.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
Informative References Informative References
[BGP-LABEL] Rekhter, Y. and E. Rosen, "Carrying Label Information [BGP-LABEL] Rekhter, Y. and E. Rosen, "Carrying Label Information
in BGP-4", RFC 3107, May 2001. in BGP-4", RFC 3107, May 2001.
[ICMP] Postel, J., "Internet Control Message Protocol", [ICMP] Postel, J., "Internet Control Message Protocol",
RFC 792. RFC 792.
[LDP] Andersson, L., et al, "LDP Specification", RFC 3036, [LDP] Andersson, L., et al, "LDP Specification", RFC 3036,
January 2001. January 2001.
skipping to change at page 37, line 43 skipping to change at page 44, line 27
draft-ietf-l3vpn-rfc2547bis-03.txt, work-in-progress. draft-ietf-l3vpn-rfc2547bis-03.txt, work-in-progress.
[PW-CONTROL] Martini, L. et al., "Pseudowire Setup and Maintenance [PW-CONTROL] Martini, L. et al., "Pseudowire Setup and Maintenance
using the Label Distribution Protocol", using the Label Distribution Protocol",
draft-ietf-pwe3-control-protocol-17.txt, draft-ietf-pwe3-control-protocol-17.txt,
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
Circuit Connectivity Verification (VCCV),
draft-ietf-pwe3-vccv-07.txt, August 2005,
work-in-progress.
[VPLS] Kompella, K. and Rekhter, Y., "Virtual Private LAN [VPLS] 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 two approaches to attacking LSRs using the mecha- There are at least three approaches to attacking LSRs using the mech-
nisms defined here. One is a Denial of Service attack, by sending anisms defined here. One is a Denial of Service attack, by sending
MPLS echo requests/replies to LSRs and thereby increasing their work- MPLS echo requests/replies to LSRs and thereby increasing their work-
load. The other is obfuscating the state of the MPLS data plane load. The second is obfuscating the state of the MPLS data plane
liveness by spoofing, hijacking, replaying or otherwise tampering liveness by spoofing, hijacking, replaying or otherwise tampering
with MPLS echo requests and replies. with MPLS echo requests and replies. The third is an unauthorized
source using an LSP Ping to obtain information about the network.
To avoid potential Denial of Service attacks, it is RECOMMENDED that To avoid potential Denial of Service attacks, it is RECOMMENDED that
implementations regulate the LSP ping traffic going to the control implementations regulate the LSP ping traffic going to the control
plane. A rate limiter SHOULD be applied to the well-known UDP port plane. A rate limiter SHOULD be applied to the well-known UDP port
defined below. defined below.
Replay and spoofing attacks are unlikely to be effective given that Unsophisticated replay and spoofing attacks involving faking or
the Sender's Handle and Sequence Number need to be valid. Thus a replaying MPLS Echo Reply Messages are unlikely to be effective.
replay would be discarded as the sequence has moved on. A spoof has These replies would have to match the the Sender's Handle and
only a small window of opportunity, however an implementation MAY Sequence Number of an outstanding MPLS Echo Request Message. A non-
provide a validation on the TimeStamp Sent to limit the window to the matching replay would be discarded as the sequence has moved on, thus
resolution of the system clock. a spoof has only a small window of opportunity. However to provide a
stronger defence, an implementation MAY also validate the TimeStamp
Sent by requiring and exact match on this field.
To protect against unauthorized sources using MPLS Echo Request mes-
sages to obtain network information, it is RECOMMENDED that implemen-
tations provides a means of checking the source addresses of MPLS
Echo Request messages against an access list before accepting the
message.
It is not clear how to prevent hijacking (non-delivery) of echo It is not clear how to prevent hijacking (non-delivery) of echo
requests or replies; however, if these messages are indeed hijacked, requests or replies; however, if these messages are indeed hijacked,
LSP ping will report that the data plane isn't working as it should. LSP ping will report that the data plane isn't working as it should.
It doesn't seem vital (at this point) to secure the data carried in It doesn't seem vital (at this point) to secure the data carried in
MPLS echo requests and replies, although knowledge of the state of MPLS echo requests and replies, although knowledge of the state of
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
used only in conjunction with the UDP port 3503. Further these pack-
ets are only processed by routers. All other hosts MUST treat all
packets with a destination address in the range 127/8 in accordance
to RFC1122. Any packet received by a router with a destination
address in the range 127/8 without a destination UDP port of 3503
MUST be treated in accordance to RFC1812.
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
defined in [IANA]); "Expert Review" and "Vendor Private Use". defined in [IANA]); "Specification Required" and "Vendor Private
Use".
Values from "Expert Review" ranges MUST be registered with IANA. The Values from "Specification Required" ranges MUST be registered with
request MUST be made via an Experimental RFC that describes the IANA. The request MUST be made via an Experimental RFC that
format and procedures for using the code point; the actual assignment describes the format and procedures for using the code point; the
is made during the IANA actions for the RFC. actual assignment is made during the IANA actions for the RFC.
Values from "Vendor Private" ranges MUST NOT be registered with IANA; Values from "Vendor Private" ranges MUST NOT be registered with IANA;
however, the message MUST contain an enterprise code as registered however, the message MUST contain an enterprise code as registered
with the IANA SMI Network Management Private Enterprise Codes. For with the IANA SMI Private Network Management Private Enterprise Num-
each name space that has a Vendor Private range, it must be specified bers. For each name space that has a Vendor Private range, it must
where exactly the SMI Enterprise Code resides; see below for exam- be specified where exactly the SMI Private Enterprise Number resides;
ples. In this way, several enterprises (vendors) can use the same see below for examples. In this way, several enterprises (vendors)
code point without fear of collision. can use the same code point without fear of collision.
7.1. Message Types, Reply Modes, Return Codes 7.1. Message Types, Reply Modes, Return Codes
It is requested that IANA maintain registries for Message Types, It is requested that IANA maintain registries for Message Types,
Reply Modes, and Return Codes. Each of these can take values in the Reply Modes, and Return Codes. Each of these can take values in the
range 0-255. Assignments in the range 0-191 are via Standards range 0-255. Assignments in the range 0-191 are via Standards
Action; assignments in the range 192-251 are made via Expert Review; Action; assignments in the range 192-251 are made via "Specification
values in the range 252-255 are for Vendor Private Use, and MUST NOT Required"; values in the range 252-255 are for Vendor Private Use,
be allocated. and MUST NOT be allocated.
If any of these fields fall in the Vendor Private range, a top-level If any of these fields fall in the Vendor Private range, a top-level
Vendor Enterprise Code TLV MUST be present in the message. Vendor Enterprise Number TLV MUST be present in the message.
Message Types defined in this document are: Message Types defined in this document are:
Value Meaning Value Meaning
----- ------- ----- -------
1 MPLS Echo Request 1 MPLS Echo Request
2 MPLS Echo Reply 2 MPLS Echo Reply
Reply Modes defined in this document are: Reply Modes defined in this document are:
skipping to change at page 40, line 15 skipping to change at page 47, line 15
7.2. TLVs 7.2. TLVs
It is requested that IANA maintain a registry for the Type field of It is requested that IANA maintain a registry for the Type field of
top-level TLVs as well as for any associated sub-TLVs. Note the top-level TLVs as well as for any associated sub-TLVs. Note the
meaning of a sub-TLV is scoped by the TLV. The number spaces for the meaning of a sub-TLV is scoped by the TLV. The number spaces for the
sub-TLVs of various TLVs are independent. sub-TLVs of various TLVs are independent.
The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the
range 0-16383 and 32768-49161 are made via Standards Action as range 0-16383 and 32768-49161 are made via Standards Action as
defined in [IANA]; assignments in the range 16384-31743 and defined in [IANA]; assignments in the range 16384-31743 and
49162-64511 are made via Expert Review as defined above; values in 49162-64511 are made via "Specification Required" as defined above;
the range 31744-32767 and 64512-65535 are for Vendor Private Use, and values in the range 31744-32767 and 64512-65535 are for Vendor Pri-
MUST NOT be allocated. vate Use, and MUST NOT be allocated.
If a TLV or sub-TLV has a Type that falls in the range for Vendor If a TLV or sub-TLV has a Type that falls in the range for Vendor
Private Use, the Length MUST be at least 4, and the first four octets Private Use, the Length MUST be at least 4, and the first four octets
MUST be that vendor's SMI Enterprise Code, in network octet order. MUST be that vendor's SMI Private Enterprise Number, in network octet
The rest of the Value field is private to the vendor. order. The rest of the Value field is private to the vendor.
TLVs and sub-TLVs defined in this document are: TLVs and sub-TLVs defined in this document are:
Type Sub-Type Value Field Type Sub-Type Value Field
---- -------- ----------- ---- -------- -----------
1 Target FEC Stack 1 Target FEC Stack
1 LDP IPv4 prefix 1 LDP IPv4 prefix
2 LDP IPv6 prefix 2 LDP IPv6 prefix
3 RSVP IPv4 LSP 3 RSVP IPv4 LSP
4 RSVP IPv6 LSP 4 RSVP IPv6 LSP
skipping to change at page 40, line 48 skipping to change at page 47, line 48
10 "FEC 128" Pseudowire 10 "FEC 128" Pseudowire
11 "FEC 129" Pseudowire 11 "FEC 129" Pseudowire
12 BGP labeled IPv4 prefix 12 BGP labeled IPv4 prefix
13 BGP labeled IPv6 prefix 13 BGP labeled IPv6 prefix
14 Generic IPv4 prefix 14 Generic IPv4 prefix
15 Generic IPv6 prefix 15 Generic IPv6 prefix
16 Nil FEC 16 Nil FEC
2 Downstream Mapping 2 Downstream Mapping
3 Pad 3 Pad
4 Not Assigned 4 Not Assigned
5 Vendor Enterprise Code 5 Vendor Enterprise Number
6 Not Assigned 6 Not Assigned
7 Interface and Label Stack 7 Interface and Label Stack
8 Not Assigned 8 Not Assigned
9 Errored TLVs 9 Errored TLVs
Any value The TLV not understood Any value The TLV not understood
10 Reply TOS Byte 10 Reply TOS Byte
8. Acknowledgments 8. Acknowledgments
This document is the outcome of many discussions among many people, This document is the outcome of many discussions among many people,
skipping to change at page 42, line 28 skipping to change at page 49, 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
May 2006 June 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. 79 change blocks. 
238 lines changed or deleted 527 lines changed or added

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