draft-ietf-mpls-lsp-ping-10.txt   draft-ietf-mpls-lsp-ping-11.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: March 2006 Expiration Date: May 2006
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
September 2005 November 2005
Detecting MPLS Data Plane Failures Detecting MPLS Data Plane Failures
draft-ietf-mpls-lsp-ping-10.txt draft-ietf-mpls-lsp-ping-11.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 5 skipping to change at page 2, line 5
Abstract Abstract
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.
Changes since last revision
(This section to be removed before publication.)
o Corrected Length of Nil Fec in the summary table at the beginning
of Sec 3.2
o Aligned the FEC 129 sub-tlv with draft-ietf-pwe3-control-
protocol-17
o Removed the duplicated Interface field from the Interface and
Label Stack object and removed the adjective "Downstream" from the
field descriptions in the text. (Sec. 3.6)
o Updated the Security section
Contents Contents
1 Introduction .............................................. 4 1 Introduction .............................................. 3
1.1 Conventions ............................................... 4 1.1 Conventions ............................................... 3
1.2 Structure of this document ................................ 4 1.2 Structure of this document ................................ 3
1.3 Contributors .............................................. 4 1.3 Contributors .............................................. 3
2 Motivation ................................................ 5 2 Motivation ................................................ 4
3 Packet Format ............................................. 6 3 Packet Format ............................................. 5
3.1 Return Codes .............................................. 10 3.1 Return Codes .............................................. 9
3.2 Target FEC Stack .......................................... 11 3.2 Target FEC Stack .......................................... 10
3.2.1 LDP IPv4 Prefix ........................................... 12 3.2.1 LDP IPv4 Prefix ........................................... 11
3.2.2 LDP IPv6 Prefix ........................................... 12 3.2.2 LDP IPv6 Prefix ........................................... 11
3.2.3 RSVP IPv4 LSP ............................................. 13 3.2.3 RSVP IPv4 LSP ............................................. 12
3.2.4 RSVP IPv6 LSP ............................................. 13 3.2.4 RSVP IPv6 LSP ............................................. 12
3.2.5 VPN IPv4 Prefix ........................................... 14 3.2.5 VPN IPv4 Prefix ........................................... 13
3.2.6 VPN IPv6 Prefix ........................................... 14 3.2.6 VPN IPv6 Prefix ........................................... 14
3.2.7 L2 VPN Endpoint ........................................... 15 3.2.7 L2 VPN Endpoint ........................................... 14
3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 15 3.2.8 FEC 128 Pseudowire (Deprecated) ........................... 15
3.2.9 FEC 128 Pseudowire (Current) .............................. 16 3.2.9 FEC 128 Pseudowire (Current) .............................. 15
3.2.10 FEC 129 Pseudowire ........................................ 16 3.2.10 FEC 129 Pseudowire ........................................ 16
3.2.11 BGP Labeled IPv4 Prefix ................................... 17 3.2.11 BGP Labeled IPv4 Prefix ................................... 16
3.2.12 BGP Labeled IPv6 Prefix ................................... 17 3.2.12 BGP Labeled IPv6 Prefix ................................... 17
3.2.13 Generic IPv4 Prefix ....................................... 18 3.2.13 Generic IPv4 Prefix ....................................... 17
3.2.14 Generic IPv6 Prefix ....................................... 18 3.2.14 Generic IPv6 Prefix ....................................... 18
3.2.15 Nil FEC ................................................... 19 3.2.15 Nil FEC ................................................... 18
3.3 Downstream Mapping ........................................ 19 3.3 Downstream Mapping ........................................ 19
3.3.1 Multipath Information Encoding ............................ 24 3.3.1 Multipath Information Encoding ............................ 23
3.3.2 Downstream Router and Interface ........................... 26 3.3.2 Downstream Router and Interface ........................... 25
3.4 Pad TLV ................................................... 26 3.4 Pad TLV ................................................... 25
3.5 Vendor Enterprise Code .................................... 27 3.5 Vendor Enterprise Code .................................... 26
3.6 Interface and Label Stack ................................. 27 3.6 Interface and Label Stack ................................. 26
3.7 Errored TLVs .............................................. 28 3.7 Errored TLVs .............................................. 28
3.8 Reply TOS Byte TLV ........................................ 29 3.8 Reply TOS Byte TLV ........................................ 28
4 Theory of Operation ....................................... 29 4 Theory of Operation ....................................... 29
4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 30 4.1 Dealing with Equal-Cost Multi-Path (ECMP) ................. 29
4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 31 4.2 Testing LSPs That Are Used to Carry MPLS Payloads ......... 30
4.3 Sending an MPLS Echo Request .............................. 31 4.3 Sending an MPLS Echo Request .............................. 30
4.4 Receiving an MPLS Echo Request ............................ 32 4.4 Receiving an MPLS Echo Request ............................ 31
4.5 Sending an MPLS Echo Reply ................................ 35 4.5 Sending an MPLS Echo Reply ................................ 34
4.6 Receiving an MPLS Echo Reply .............................. 36 4.6 Receiving an MPLS Echo Reply .............................. 35
4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 36 4.7 Issue with VPN IPv4 and IPv6 Prefixes ..................... 36
4.8 Non-compliant Routers ..................................... 37 4.8 Non-compliant Routers ..................................... 36
5 References ................................................ 37 5 References ................................................ 37
6 Security Considerations ................................... 38 6 Security Considerations ................................... 38
7 IANA Considerations ....................................... 38 7 IANA Considerations ....................................... 38
7.1 Message Types, Reply Modes, Return Codes .................. 39 7.1 Message Types, Reply Modes, Return Codes .................. 39
7.2 TLVs ...................................................... 40 7.2 TLVs ...................................................... 40
8 Acknowledgments ........................................... 41 8 Acknowledgments ........................................... 41
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
skipping to change at page 4, line 30 skipping to change at page 3, line 30
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.
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
reserved fields. These fields MUST be set to zero when sent and
ignored on receipt.
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 21 skipping to change at page 4, line 24
isolate faults. isolate faults.
In this document, we describe a mechanism that accomplishes these In this document, we describe a mechanism that accomplishes these
goals. This mechanism is modeled after the ping/traceroute paradigm: goals. This mechanism is modeled after the ping/traceroute paradigm:
ping (ICMP echo request [ICMP]) is used for connectivity checks, and ping (ICMP echo request [ICMP]) is used for connectivity checks, and
traceroute is used for hop-by-hop fault localization as well as path traceroute is used for hop-by-hop fault localization as well as path
tracing. This document specifies a "ping mode" and a "traceroute" tracing. This document specifies a "ping mode" and a "traceroute"
mode for testing MPLS LSPs. mode for testing MPLS LSPs.
The basic idea is to verify that packets that belong to a particular The basic idea is to verify that packets that belong to a particular
Forwarding Equivalence Class (FEC) actually end their MPLS path on an Forwarding Equivalence Class (FEC) actually end their MPLS path on a
LSR that is an egress for that FEC. This document proposes that this Label Switching Router (LSR) that is an egress for that FEC. This
test be carried out by sending a packet (called an "MPLS echo document proposes that this test be carried out by sending a packet
request") along the same data path as other packets belonging to this (called an "MPLS echo request") along the same data path as other
FEC. An MPLS echo request also carries information about the FEC packets belonging to this FEC. An MPLS echo request also carries
whose MPLS path is being verified. This echo request is forwarded information about the FEC whose MPLS path is being verified. This
just like any other packet belonging to that FEC. In "ping" mode echo request is forwarded just like any other packet belonging to
(basic connectivity check), the packet should reach the end of the that FEC. In "ping" mode (basic connectivity check), the packet
path, at which point it is sent to the control plane of the egress should reach the end of the path, at which point it is sent to the
LSR, which then verifies whether it is indeed an egress for the FEC. control plane of the egress LSR, which then verifies whether it is
In "traceroute" mode (fault isolation), the packet is sent to the indeed an egress for the FEC. In "traceroute" mode (fault isola-
control plane of each transit LSR, which performs various checks that tion), the packet is sent to the control plane of each transit LSR,
it is indeed a transit LSR for this path; this LSR also returns fur- which performs various checks that it is indeed a transit LSR for
ther information that helps check the control plane against the data this path; this LSR also returns further information that helps check
plane, i.e., that forwarding matches what the routing protocols the control plane against the data plane, i.e., that forwarding
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.
3. Packet Format 3. Packet Format
skipping to change at page 7, line 27 skipping to change at page 6, line 27
The Reply Mode can take one of the following values: The Reply Mode can take one of the following values:
Value Meaning Value Meaning
----- ------- ----- -------
1 Do not reply 1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet 2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert 3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application level control channel 4 Reply via application level control channel
An MPLS echo request with "Do not reply" may be used for one-way con- An MPLS echo request with 1 (Do not reply) in the Reply Mode field
nectivity tests; the receiving router may log gaps in the sequence may be used for one-way connectivity tests; the receiving router may
numbers and/or maintain delay/jitter statistics. An MPLS echo log gaps in the sequence numbers and/or maintain delay/jitter statis-
request would normally have "Reply via an IPv4/IPv6 UDP packet"; if tics. An MPLS echo request would normally have 2 (Reply via an
the normal IP return path is deemed unreliable, one may use "Reply IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP
via an IPv4/IPv6 UDP packet with Router Alert" (note that this return path is deemed unreliable, one may use 3 (Reply via an
requires that all intermediate routers understand and know how to IPv4/IPv6 UDP packet with Router Alert). Note that this requires
forward MPLS echo replies). The echo reply uses the same IP version that all intermediate routers understand and know how to forward MPLS
number as the received echo request, i.e., an IPv4 encapsulated echo echo replies. The echo reply uses the same IP version number as the
reply is sent in response to an IPv4 encapsulated echo request. received echo request, i.e., an IPv4 encapsulated echo reply is sent
in response to an IPv4 encapsulated echo request.
Any application which supports an IP control channel between its con- Any application which supports an IP control channel between its con-
trol entities may set the Reply Mode to 4 to ensure that replies use trol entities may set the Reply Mode to 4 (Reply via application
that same channel. Further definition of this codepoint is applica- level control channel) to ensure that replies use that same channel.
tion specific and thus beyond the scope of this document. 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,
wrt the sender's clock) when the MPLS echo request is sent. The according to the sender's clock) when the MPLS echo request is sent.
TimeStamp Received in an echo reply is the time-of-day (wrt the The TimeStamp Received in an echo reply is the time-of-day (according
receiver's clock) that the corresponding echo request was received. to the receiver's clock) that 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 44 skipping to change at page 7, line 48
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 = 1 (LDP IPv4 FEC) | Length = 5 | | Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length for this TLV is 5. A Target FEC Stack TLV which contains The Length for this TLV is 5. A Target FEC Stack TLV which contains
an LDP IPv4 FEC sub-TLV and a VPN IPv4 FEC sub-TLV has the format: an LDP IPv4 FEC sub-TLV and a VPN IPv4 prefix sub-TLV has the 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 = 1 (FEC TLV) | Length = 12 | | Type = 1 (FEC TLV) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 1 (LDP IPv4 FEC) | Length = 5 | | sub-Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 6 (VPN IPv4 FEC) | Length = 13 | | sub-Type = 6 (VPN IPv4 prefix)| Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
skipping to change at page 11, line 42 skipping to change at page 10, line 42
15 17 Generic IPv6 prefix 15 17 Generic IPv6 prefix
16 4 Nil FEC 16 4 Nil FEC
Other FEC Types will be defined as needed. Other FEC Types will be defined as needed.
Note that this TLV defines a stack of FECs, the first FEC element Note that this TLV defines a stack of FECs, the first FEC element
corresponding to the top of the label stack, etc. corresponding to the top of the label stack, etc.
An MPLS echo request MUST have a Target FEC Stack that describes the An MPLS echo request MUST have a Target FEC Stack that describes the
FEC stack being tested. For example, if an LSR X has an LDP mapping FEC stack being tested. For example, if an LSR X has an LDP mapping
for 192.168.1.1 (say label 1001), then to verify that label 1001 does [see LDP] for 192.168.1.1 (say label 1001), then to verify that label
indeed reach an egress LSR that announced this prefix via LDP, X can 1001 does indeed reach an egress LSR that announced this prefix via
send an MPLS echo request with a FEC Stack TLV with one FEC in it, LDP, X can send an MPLS echo request with a FEC Stack TLV with one
namely of type LDP IPv4 prefix, with prefix 192.168.1.1/32, and send FEC in it, namely of type LDP IPv4 prefix, with prefix
the echo request with a label of 1001. 192.168.1.1/32, and send the echo request with a label of 1001.
Say LSR X wanted to verify that a label stack of <1001, 23456> is the Say LSR X wanted to verify that a label stack of <1001, 23456> is the
right label stack to use to reach a VPN IPv4 prefix of 10/8 in VPN right label stack to use to reach a VPN IPv4 prefix [see section
foo. Say further that LSR Y with loopback address 192.168.1.1 3.2.5] of 10/8 in VPN foo. Say further that LSR Y with loopback
announced prefix 10/8 with Route Distinguisher RD-foo-Y (which may in address 192.168.1.1 announced prefix 10/8 with Route Distinguisher
general be different from the Route Distinguisher that LSR X uses in RD-foo-Y (which may in general be different from the Route Distin-
its own advertisements for VPN foo), label 23456 and BGP nexthop guisher that LSR X uses in its own advertisements for VPN foo), label
192.168.1.1. Finally, suppose that LSR X receives a label binding of 23456 and BGP nexthop 192.168.1.1 [see BGP]. Finally, suppose that
1001 for 192.168.1.1 via LDP. X has two choices in sending an MPLS LSR X receives a label binding of 1001 for 192.168.1.1 via LDP. X
echo request: X can send an MPLS echo request with a FEC Stack TLV has two choices in sending an MPLS echo request: X can send an MPLS
with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 and a echo request with a FEC Stack TLV with a single FEC of type VPN IPv4
Route Distinguisher of RD-foo-Y. Alternatively, X can send a FEC prefix with a prefix of 10/8 and a Route Distinguisher of RD-foo-Y.
Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of Alternatively, X can send a FEC Stack TLV with two FECs, the first of
192.168.1.1/32 and the second of type of IP VPN with a prefix 10/8 type LDP IPv4 with a prefix of 192.168.1.1/32 and the second of type
with Route Distinguisher of RD-foo-Y. In either case, the MPLS echo of IP VPN with a prefix 10/8 with Route Distinguisher of RD-foo-Y.
request would have a label stack of <1001, 23456>. (Note: in this In either case, the MPLS echo request would have a label stack of
example, 1001 is the "outer" label and 23456 is the "inner" label.) <1001, 23456>. (Note: in this example, 1001 is the "outer" label and
23456 is the "inner" label.)
3.2.1. LDP IPv4 Prefix 3.2.1. LDP IPv4 Prefix
The value consists of four octets of an IPv4 prefix followed by one The IPv4 Prefix FEC is defined in [LDP]. When a LDP IPv4 prefix is
octet of prefix length in bits; the format is given below. The IPv4 encoded in a label stack, the following format is used. The value
prefix is in network byte order; if the prefix is shorter than 32 consists of four octets of an IPv4 prefix followed by one octet of
bits, trailing bits SHOULD be set to zero. See [LDP] for an example prefix length in bits; the format is given below. The IPv4 prefix is
of a Mapping for an IPv4 FEC. in network byte order; if the prefix is shorter than 32 bits, trail-
ing bits SHOULD be set to zero. See [LDP] for an example of a Map-
ping for an IPv4 FEC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.2. LDP IPv6 Prefix 3.2.2. LDP IPv6 Prefix
The value consists of sixteen octets of an IPv6 prefix followed by The IPv6 Prefix FEC is defined in [LDP]. When a LDP IPv6 prefix is
one octet of prefix length in bits; the format is given below. The encoded in a label stack, the following format is used. The value
IPv6 prefix is in network byte order; if the prefix is shorter than consists of sixteen octets of an IPv6 prefix followed by one octet of
128 bits, the trailing bits SHOULD be set to zero. See [LDP] for an prefix length in bits; the format is given below. The IPv6 prefix is
example of a Mapping for an IPv6 FEC. in network byte order; if the prefix is shorter than 128 bits, the
trailing bits SHOULD be set to zero. See [LDP] for an example of a
Mapping for an IPv6 FEC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix | | IPv6 prefix |
| (16 octets) | | (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.3. RSVP IPv4 LSP 3.2.3. RSVP IPv4 LSP
The value has the format below. The value fields are taken from The value has the format below. The value fields are taken from
[RFC3209, sections 4.6.1.1 and 4.6.2.1]. RFC3209, sections 4.6.1.1 and 4.6.2.1. See [RSVP-TE].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address | | IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.4. RSVP IPv6 LSP 3.2.4. RSVP IPv6 LSP
The value has the format below. The value fields are taken from The value has the format below. The value fields are taken from
[RFC3209, sections 4.6.1.2 and 4.6.2.2]. RFC3209, sections 4.6.1.2 and 4.6.2.2. See [RSVP-TE].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address | | IPv6 tunnel end point address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
skipping to change at page 14, line 30 skipping to change at page 13, line 30
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.5. VPN IPv4 Prefix 3.2.5. VPN IPv4 Prefix
The value field consists of the Route Distinguisher advertised with VPN-IPv4 NLRI (Network Layer Routing Information) is defined in
the VPN IPv4 prefix, the IPv4 prefix (with trailing 0 bits to make 32 [MPLS-L3-VPN]. This document uses the term VPN IPv4 prefix for a
bits in all) and a prefix length, as follows: VPN-IPv4 NLRI which has been advertised with an MPLS label in BGP.
See [BGP-LABEL].
When a VPN IPv4 prefix is encoded in a label stack, the following
format is used. The value field consists of the Route Distinguisher
advertised with the VPN IPv4 prefix, the IPv4 prefix (with trailing 0
bits to make 32 bits in all) and a prefix length, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.6. VPN IPv6 Prefix 3.2.6. VPN IPv6 Prefix
The value field consists of the Route Distinguisher advertised with VPN-IPv6 NLRI (Network Layer Routing Information) is defined in
the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 bits to make [MPLS-L3-VPN]. This document uses the term VPN IPv6 prefix for a
128 bits in all) and a prefix length, as follows: VPN-IPv6 NLRI which has been advertised with an MPLS label in BGP.
See [BGP-LABEL].
When a VPN IPv6 prefix is encoded in a label stack, the following
format is used. The value field consists of the Route Distinguisher
advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0
bits to make 128 bits in all) and a prefix length, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix | | IPv6 prefix |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.7. L2 VPN Endpoint 3.2.7. L2 VPN Endpoint
The value field consists of a Route Distinguisher (8 octets), the VPLS BGP NLRI and VE ID are defined in [VPLS]. This document uses
sender (of the ping)'s VE ID (2 octets), the receiver's VE ID (2 the simpler term L2 VPN endpoint when refering to a VPLS BGP NLRI.
octets), and an encapsulation type (2 octets), formatted as follows: 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
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
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)
The value field consists of the remote PE address (the destination FEC 128 and the term VC ID are defined in [PW-CONTROL]. 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 destination
address of the targeted LDP session), a VC ID and an encapsulation address of the targeted LDP session), a VC ID and an encapsulation
type, as follows: 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 | | VC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero | | Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This FEC will be deprecated, and is retained only for backward com- This FEC is deprecated and is retained only for backward compatibil-
patibility. Implementations of LSP ping SHOULD accept and process ity. Implementations of LSP ping SHOULD accept and process this TLV,
this TLV, but SHOULD send LSP ping echo requests with the new TLV but SHOULD send LSP ping echo requests with the new TLV (see next
(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)
The value field consists of the sender's PE address (the source FEC 128 and the term VC ID are defined in [PW-CONTROL]. When a FEC
address of the targeted LDP session), the remote PE address (the des- 128 is encoded in a label stack, the following format is used. The
tination address of the targeted LDP session), a VC ID and an encap- value field consists of the sender's PE address (the source address
sulation type, as follows: of the targeted LDP session), the remote PE address (the destination
address of the targeted LDP session), a VC ID and an 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 | | VC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero | | Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.10. FEC 129 Pseudowire 3.2.10. FEC 129 Pseudowire
The Length of this TLV is 16 + AGI length + SAII length + TAII FEC 129 and the terms AII, AGI, SAII, and TAII are defined in [PW-
length. Padding is used to make the total length a multiple of 4; CONTROL]. When a FEC 129 is encoded in a label stack, the following
the length of the padding is not included in the Length field. 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 17, line 31 skipping to change at page 16, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | Value | | AII Type | TAII Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~ ~ TAII Value (contd.) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.)| 0-3 octets of zero padding | | Value (cont.)| 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.11. BGP Labeled IPv4 Prefix 3.2.11. BGP Labeled IPv4 Prefix
The value field consists the IPv4 prefix (with trailing 0 bits to BGP labeled IPv4 prefixes are defined in [BGP-LABEL]. When a BGP
make 32 bits in all), and the prefix length, as follows: labeled IPv4 prefix is encoded in a label stack, the following format
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:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix | | IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.12. BGP Labeled IPv6 Prefix 3.2.12. BGP Labeled IPv6 Prefix
The value consists of sixteen octets of an IPv6 prefix followed by BGP labeled IPv6 prefixes are defined in [BGP-LABEL]. When a BGP
one octet of prefix length in bits; the format is given below. The labeled IPv6 prefix is encoded in a label stack, the following format
IPv6 prefix is in network byte order; if the prefix is shorter than is used. The value consists of sixteen octets of an IPv6 prefix fol-
128 bits, the trailing bits SHOULD be set to zero. lowed by one octet of prefix length in bits; the format is given
below. The IPv6 prefix is in network byte order; if the prefix is
shorter than 128 bits, the trailing bits SHOULD be set to zero.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix | | IPv6 prefix |
| (16 octets) | | (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.13. Generic IPv4 Prefix 3.2.13. Generic IPv4 Prefix
The value consists of four octets of an IPv4 prefix followed by one The value consists of four octets of an IPv4 prefix followed by one
octet of prefix length in bits; the format is given below. The IPv4 octet of prefix length in bits; the format is given below. The IPv4
prefix is in network byte order; if the prefix is shorter than 32 prefix is in network byte order; if the prefix is shorter than 32
bits, trailing bits SHOULD be set to zero. This FEC is used if the bits, trailing bits SHOULD be set to zero. This FEC is used if the
protocol advertising the label is unknown, or may change during the protocol advertising the label is unknown, or may change during the
course of the LSP. An example is an inter-AS LSP that may be sig- course of the LSP. An example is an inter-AS LSP that may be sig-
naled by LDP in one AS, by RSVP-TE in another AS, and by BGP between naled by LDP in one AS, by RSVP-TE [RSVP-TE] in another AS, and by
the ASes, such as is common for inter-AS VPNs. BGP between the ASes, such as is common for inter-AS VPNs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.14. Generic IPv6 Prefix 3.2.14. Generic IPv6 Prefix
skipping to change at page 19, line 48 skipping to change at page 19, line 16
3.3. Downstream Mapping 3.3. Downstream Mapping
The Downstream Mapping object is a TLV which MAY be included in an The Downstream Mapping object is a TLV which MAY be included in an
echo request message. Only one Downstream Mapping object may appear echo request message. Only one Downstream Mapping object may appear
in an echo request. The presence of a Downstream Mapping object is a in an echo request. The presence of a Downstream Mapping object is a
request that Downstream Mapping objects be included in the echo request that Downstream Mapping objects be included in the echo
reply. If the replying router is the destination of the FEC, then a reply. If the replying router is the destination of the FEC, then a
Downstream Mapping TLV SHOULD NOT be included in the echo reply. Downstream Mapping TLV SHOULD NOT be included in the echo reply.
Otherwise the replying router SHOULD include a Downstream Mapping Otherwise the replying router SHOULD include a Downstream Mapping
object for each interface over which this FEC could be forwarded. object for each interface over which this FEC could be forwarded.
For a more precise definition of the notion of "downstream", see the For a more precise definition of the notion of "downstream", see sec-
section named "Downstream". tion 3.3.2, "Downstream Router and Interface".
The Length is K + M + 4*N octets, where M is the Multipath Length, The Length is K + M + 4*N octets, where M is the Multipath Length,
and N is the number of Downstream Labels. Values for K are found in and N is the number of Downstream Labels. Values for K are found in
the description of Address Type below. The Value field of a Down- the description of Address Type below. The Value field of a Down-
stream Mapping has the following format: stream Mapping has 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags | | MTU | Address Type | DS Flags |
skipping to change at page 20, line 36 skipping to change at page 20, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol | | Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximum Transmission Unit (MTU) Maximum Transmission Unit (MTU)
The MTU is the largest MPLS frame (including label stack) that fits The MTU is the size in octets of the largest MPLS frame (including
on the interface to the Downstream LSR. label stack) that fits on the interface to the Downstream LSR.
Address Type Address Type
The Address Type indicates if the interface is numbered or unnum- The Address Type indicates if the interface is numbered or unnum-
bered. It also determines the length of the Downstream IP Address bered. It also determines the length of the Downstream IP Address
and Downstream Interface fields. The resulting total for the initial and Downstream Interface fields. The resulting total for the initial
part of the TLV is listed in the table below as "K Octets". The part of the TLV is listed in the table below as "K Octets". The
Address Type is set to one of the following values: Address Type is set to one of the following values:
Type # Address Type K Octets Type # Address Type K Octets
skipping to change at page 22, line 35 skipping to change at page 22, line 15
Unnumbered. For IPv4 it MUST set the Downstream IP Address to Unnumbered. For IPv4 it MUST set the Downstream IP Address to
224.0.0.2, for IPv6 the address MUST be set to FF02::2. In both 224.0.0.2, for IPv6 the address MUST be set to FF02::2. In both
cases the interface index MUST be set to 0. If an LSR receives an cases the interface index MUST be set to 0. If an LSR receives an
Echo Request packet with the all-routers multicast address, then this Echo Request packet with the all-routers multicast address, then this
indicates that it MUST bypass both interface and label stack valida- indicates that it MUST bypass both interface and label stack valida-
tion, but return Downstream Mapping TLVs using the information pro- tion, but return Downstream Mapping TLVs using the information pro-
vided. vided.
Multipath Type Multipath Type
The following Mutipath 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 IPv4 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
skipping to change at page 28, line 46 skipping to change at page 28, line 16
The label stack of the received echo request message. If any TTL The label stack of the received echo request message. If any TTL
values have been changed by this router, they SHOULD be restored. values have been changed by this router, they SHOULD be restored.
3.7. Errored TLVs 3.7. Errored TLVs
The following TLV is a TLV which MAY be included in an echo reply to The following TLV is a TLV which MAY be included in an echo reply to
inform the sender of an echo request of Mandatory TLVs either not inform the sender of an echo request of Mandatory TLVs either not
supported by an implementation, or parsed and found to be in error. supported by an implementation, or parsed and found to be in error.
The Value field contains the TLVs not understood encoded as sub-TLVs. The Value field contains the TLVs that were not understood, encoded
as sub-TLVs.
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 = 9 | Length | | Type = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
. . . .
. . . .
. . . .
skipping to change at page 36, line 41 skipping to change at page 36, line 9
echo reply is received for a given Sequence Number (for a given UDP echo reply is received for a given Sequence Number (for a given UDP
port and Handle), the Sequence Number for subsequent echo requests port and Handle), the Sequence Number for subsequent echo requests
for that UDP port and Handle SHOULD be incremented. 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 or IPv6 prefix is sent with a Typically, a LSP ping for a VPN IPv4 prefix or VPN IPv6 prefix is
label stack of depth greater than 1, with the innermost label having sent with a label stack of depth greater than 1, with the innermost
a TTL of 1. This is to terminate the ping at the egress PE, before label having a TTL of 1. This is to terminate the ping at the egress
it gets sent to the customer device. However, under certain circum- PE, before it gets sent to the customer device. However, under cer-
stances, the label stack can shrink to a single label before the ping tain circumstances, the label stack can shrink to a single label
hits the egress PE; this will result in the ping terminating prema- before the ping hits the egress PE; this will result in the ping ter-
turely. One such scenario is a multi-AS Carrier's Carrier VPN. minating prematurely. One such scenario is a multi-AS Carrier's Car-
rier VPN.
To get around this problem, one approach is for the LSR that receives To get around this problem, one approach is for the LSR that receives
such a ping to realize that the ping terminated prematurely, and send such a ping to realize that the ping terminated prematurely, and send
back error code 13. In that case, the initiating LSR can retry the back error code 13. In that case, the initiating LSR can retry the
ping after incrementing the TTL on the VPN label. In this fashion, ping after incrementing the TTL on the VPN label. In this fashion,
the ingress LSR will sequentially try TTL values until it finds one the ingress LSR will sequentially try TTL values until it finds one
that allows the VPN ping to reach the egress PE. that allows the VPN ping to reach the egress PE.
4.8. Non-compliant Routers 4.8. Non-compliant Routers
skipping to change at page 37, line 29 skipping to change at page 37, line 9
the ALLROUTERs multicast address until a reply is received with a the ALLROUTERs multicast address until a reply is received with a
Downstream Mapping TLV. The Label Stack MAY be omitted from the Downstream Mapping TLV. The Label Stack MAY be omitted from the
Downstream Mapping TLV. Further the "Validate FEC Stack" flag SHOULD Downstream Mapping TLV. Further the "Validate FEC Stack" flag SHOULD
NOT be set until an echo reply packet with a Downstream Mapping TLV NOT be set until an echo reply packet with a Downstream Mapping TLV
is received. is received.
5. References 5. References
Normative References Normative References
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[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.
Informative References Informative References
[BGP-LABEL] Rekhter, Y. and E. Rosen, "Carrying Label Information
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.
[MPLS-L3-VPN] Rekhter, Y. & Rosen, E., "BGP/MPLS IP VPNs",
draft-ietf-l3vpn-rfc2547bis-03.txt, work-in-progress.
[PW-CONTROL] Martini, L. et al., "Pseudowire Setup and Maintenance
using the Label Distribution Protocol",
draft-ietf-pwe3-control-protocol-17.txt,
work-in-progress.
[RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[VPLS] Kompella, K. and Rekhter, Y., "Virtual Private LAN
Service", draft-ietf-l2vpn-vpls-bgp-05,
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 two approaches to attacking LSRs using the mecha-
nisms defined here. One is a Denial of Service attack, by sending nisms 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 other 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
skipping to change at page 38, line 50 skipping to change at page 38, line 50
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]); "Expert Review" and "Vendor Private Use".
Values from "Expert Review" ranges MUST be registered with IANA, and Values from "Expert Review" ranges MUST be registered with IANA. The
MUST be accompanied by an Experimental RFC that describes the format request MUST be made via an Experimental RFC that describes the
and procedures for using the code point; the actual assignment is format and procedures for using the code point; the actual assignment
made during the IANA actions for the RFC. 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 Network Management Private Enterprise Codes. For
each name space that has a Vendor Private range, it must be specified each name space that has a Vendor Private range, it must be specified
where exactly the SMI Enterprise Code resides; see below for exam- where exactly the SMI Enterprise Code resides; see below for exam-
ples. In this way, several enterprises (vendors) can use the same ples. In this way, several enterprises (vendors) can use the same
code point without fear of collision. code point without fear of collision.
7.1. Message Types, Reply Modes, Return Codes 7.1. Message Types, Reply Modes, Return Codes
skipping to change at page 40, line 9 skipping to change at page 40, line 9
2 Reply via an IPv4/IPv6 UDP packet 2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert 3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application level control channel 4 Reply via application level control channel
Return Codes defined in this document are listed in section 3.1. Return Codes defined in this document are listed in section 3.1.
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 valid range for each meaning of a sub-TLV is scoped by the TLV. The number spaces for the
of these is 0-65535. Assignments in the range 0-16383 and sub-TLVs of various TLVs are independent.
32768-49161 are made via Standards Action as defined in [IANA];
assignments in the range 16384-31743 and 49162-64511 are made via The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the
Expert Review (see below); values in the range 31744-32746 and range 0-16383 and 32768-49161 are made via Standards Action as
64512-65535 are for Vendor Private Use, and MUST NOT be allocated. defined in [IANA]; assignments in the range 16384-31743 and
49162-64511 are made via Expert Review as defined above; values in
the range 31744-32767 and 64512-65535 are for Vendor Private 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 Enterprise Code, in network octet order.
The rest of the Value field is private to the vendor. 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
---- -------- ----------- ---- -------- -----------
skipping to change at page 42, line 5 skipping to change at page 42, line 5
This document is the outcome of many discussions among many people, This document is the outcome of many discussions among many people,
that include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa that include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa
Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani Aggarwal and Vanson Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani Aggarwal and Vanson
Lim. Lim.
The description of the Multipath Information sub-field of the Down- The description of the Multipath Information sub-field of the Down-
stream Mapping TLV was adapted from text suggested by Curtis Vil- stream Mapping TLV was adapted from text suggested by Curtis Vil-
lamizar. lamizar.
Authors' Address Authors' Addresses
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: kireeti@juniper.net Email: kireeti@juniper.net
George Swallow George Swallow
Cisco Systems Cisco Systems
1414 Massachusetts Ave, 1414 Massachusetts Ave,
skipping to change at page 42, line 28 skipping to change at page 42, 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
March 2006 May 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. 49 change blocks. 
170 lines changed or deleted 219 lines changed or added

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