draft-ietf-mpls-lsp-ping-00.txt | draft-ietf-mpls-lsp-ping-01.txt | |||
---|---|---|---|---|
Network Working Group Kireeti Kompella (Juniper) | Network Working Group K. Kompella (Juniper) | |||
Internet Draft Ping Pan (Juniper) | Internet Draft P. Pan (Ciena) | |||
Expiration Date: September 2002 Nischal Sheth (Juniper) | draft-ietf-mpls-lsp-ping-01.txt N. Sheth (Juniper) | |||
Network Working Group Dave Cooper (Global Crossing) | Category: Standards Track D. Cooper (Global Crossing) | |||
George Swallow (Cisco) | Expires: April 2003 G. Swallow (Cisco) | |||
Sanjay Wadhwa (Unisphere) | S. Wadhwa (Juniper) | |||
Ron Bonica (Worldcom) | R. Bonica (WorldCom) | |||
October 2002 | ||||
Detecting Data Plane Liveliness in MPLS | Detecting MPLS Data Plane Liveness | |||
draft-ietf-mpls-lsp-ping-00.txt | *** DRAFT *** | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with all | This document is an Internet-Draft and is in full conformance with | |||
provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering Task | Internet-Drafts are working documents of the Internet Engineering | |||
Force (IETF), its areas, and its working groups. Note that other groups | Task Force (IETF), its areas, and its working groups. Note that | |||
may also distribute working documents as Internet-Drafts. | other groups may also distribute working documents as Internet- | |||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference material | time. It is inappropriate to use Internet-Drafts as reference | |||
or to cite them other than as ``work in progress.'' | material or to cite them other than as ``work in progress.'' | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Copyright Notice | ||||
Copyright (C) The Internet Society (2002). All Rights Reserved. | ||||
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 MPLS LSPs. There are two parts to | used to detect data plane failures in Multi-Protocol Label Switching | |||
this document: information carried in an MPLS "echo request" and "echo | (MPLS) Label Switched Paths (LSPs). There are two parts to this | |||
reply" for the purposes of fault detection and isolation; and mechanisms | document: information carried in an MPLS "echo request" and "echo | |||
for transporting the echo reply. | reply" for the purposes of fault detection and isolation; and | |||
mechanisms for reliably sending the echo reply. | ||||
Sub-IP ID Summary | Sub-IP ID Summary | |||
(This section to be removed before publication.) | ||||
(See Abstract above.) | (See Abstract above.) | |||
RELATED DOCUMENTS | RELATED DOCUMENTS | |||
May be found in the "references" section. | May be found in the "references" section. | |||
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK | WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK | |||
Fits in the MPLS box. | Fits in the MPLS box. | |||
WHY IS IT TARGETED AT THIS WG | WHY IS IT TARGETED AT THIS WG | |||
MPLS WG is currently looking at MPLS-specific error detection and | MPLS WG is currently looking at MPLS-specific error detection and | |||
recovery mechanisms. The mechanisms proposed here are for packet-based | recovery mechanisms. The mechanisms proposed here are for packet- | |||
MPLS LSPs, which is why the MPLS WG is targeted. | based MPLS LSPs, which is why the MPLS WG is targeted. | |||
JUSTIFICATION | JUSTIFICATION | |||
The WG should consider this document, as it allows network operators to | The WG should consider this document, as it allows network operators | |||
detect MPLS LSP data plane failures in the network. This type of | to detect MPLS LSP data plane failures in the network. This type of | |||
failures have occurred, and are a source of concern to operators | failures have occurred, and are a source of concern to operators | |||
implementing MPLS networks. | implementing MPLS networks. | |||
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 | |||
skipping to change at page 3, line 5 | skipping to change at page 3, line 28 | |||
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 | Mechanisms to check the control plane are valuable, but are not | |||
covered in this document. | covered in this document. | |||
To avoid potential Denial of Service attacks, it is recommended to | To avoid potential Denial of Service attacks, it is recommended to | |||
regulate the MPLS ping traffic going to the control plane. A rate | regulate the MPLS ping traffic going to the control plane. A rate | |||
limiter should be applied to the well-known UDP port defined below. | limiter should be applied to the well-known UDP port defined below. | |||
1.1. Conventions | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
document are to be interpreted as described in RFC 2119 [KEYWORDS]. | ||||
1.2. Changes since last revision | ||||
(This section to be removed before publication.) | ||||
- Packet format changed; Version Number field added | ||||
- Reply modes: "don't reply" added | ||||
- Reply flags removed | ||||
- Return codes extended | ||||
- RSVP session formats modified | ||||
- VPN IPv4/v6 formats defined | ||||
- L2 VPN endpoint and L2 circuits defined | ||||
- Downstream mapping format changed | ||||
- Pad and Error Code TLVs introduced | ||||
- Aspects dealing with CR-LDP moved to non-normative appendix | ||||
- IPR notices and Full Copyright Statement (per 2026) added | ||||
- other nits to better conform to 2223bis | ||||
2. Motivation | 2. Motivation | |||
When an LSP fails to deliver user traffic, the failure cannot always | When an LSP fails to deliver user traffic, the failure cannot always | |||
be detected by the MPLS control plane. There is a need to provide a | be detected by the MPLS control plane. There is a need to provide a | |||
tool that would enable users to detect such traffic "black holes" or | tool that would enable users to detect such traffic "black holes" or | |||
misrouting within a reasonable period of time; and a mechanism to | misrouting within a reasonable period of time; and a mechanism to | |||
isolate faults. | isolate faults. | |||
In this document, we describe a mechanism, termed "MPLS ping", that | In this document, we describe a mechanism that accomplishes these | |||
accomplishes these goals. This mechanism is modeled after the ICMP | goals. This mechanism is modeled after the ping/traceroute | |||
echo request/reply, used by ping and traceroute to detect and | philosophy: ping (ICMP echo request [ICMP]) is used for connectivity | |||
localize faults in IP networks. This document also offers some | checks, and traceroute is used for hop-by-hop fault localization as | |||
alternative methods for replying to MPLS echo requests. | well as path tracing. This document specifies a "ping mode" and a | |||
"traceroute" mode for testing MPLS LSPs. | ||||
The basic idea is to test that packets that belong to a particular | The basic idea is to test 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 an | |||
LSR that is an egress for that FEC. Therefore, an MPLS echo request | LSR that is an egress for that FEC. This document proposes that this | |||
carries information about the FEC whose MPLS path is being verified. | test be carried out by sending a packet (called an "MPLS echo | |||
This echo request is forwarded just like any other packet belonging | request") along the same data path as other packets belonging to this | |||
to that FEC. In "ping" mode (basic connectivity check), the packet | FEC. An MPLS echo request also carries information about the FEC | |||
should reach the end of the path, at which point it is sent to the | whose MPLS path is being verified. This echo request is forwarded | |||
control plane of the egress LSR, which then verifies that it is | just like any other packet belonging to that FEC. In "ping" mode | |||
indeed an egress for the FEC. In "traceroute" mode (fault | (basic connectivity check), the packet should reach the end of the | |||
isolation), the packet is sent to the control plane of each transit | path, at which point it is sent to the control plane of the egress | |||
LSR, which performs various checks that it is indeed a transit LSR | LSR, which then verifies that it is indeed an egress for the FEC. In | |||
for this path; this LSR also returns further information that helps | "traceroute" mode (fault isolation), the packet is sent to the | |||
check the control plane against the data plane, i.e., that forwarding | control plane of each transit LSR, which performs various checks that | |||
matches what the routing protocols determined as the path. | it is indeed a transit LSR for this path; this LSR also returns | |||
further information that helps check the control plane against the | ||||
data plane, i.e., that forwarding 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 | traceroute to determine where the fault lies. One can also | |||
periodically traceroute FECs to verify that forwarding matches the | periodically traceroute FECs to verify that forwarding matches the | |||
control plane; however, this places a greater burden on transit LSRs | control plane; however, this places a greater burden on transit LSRs | |||
and thus should be used with caution. | and thus should be used with caution. | |||
3. Packet Format | 3. Packet Format | |||
An MPLS ping packet is a (possibly labelled) UDP packet with the | An MPLS echo request is a (possibly labelled) UDP packet; the | |||
following payload format: | 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 | Must Be Zero | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Message Type | Reply mode | Return Code | Return Subcode| | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender's Handle | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sequence Number | | | Sequence Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| TimeStamp (seconds) | | | TimeStamp Sent (seconds) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| TimeStamp (microseconds) | | | TimeStamp Sent (microseconds) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Reply mode | Reply flags | Return Code | Must be zero | | | TimeStamp Received (seconds) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| TimeStamp Received (microseconds) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| TLVs ... | | | TLVs ... | | |||
. . | . . | |||
. . | . . | |||
. . | . . | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
The Sequence Number is assigned by the sender of the MPLS echo | The Version Number is currently 1. (Note: the Version Number is to | |||
request, and can be used to detect missed replies (for example). | be incremented whenever a change is made that affects the ability of | |||
an implementation to correctly parse or process an MPLS echo | ||||
The TimeStamp is set to the time of day (in seconds and microseconds) | request/reply. These changes include any syntactic or semantic | |||
when the MPLS echo request or reply is sent, and may be used to | changes made to any of the fixed fields, or to any TLV or sub-TLV | |||
compute delay or round trip time (for example). | assignment or format that is defined at a certain version number. | |||
The Version Number may not need to be changed if a TLV or sub-TLV is | ||||
added.) | ||||
The Reply Mode can take one of the following values: | The Message Type is one of the following: | |||
Value Meaning | Value Meaning | |||
----- ------- | ----- ------- | |||
1 Reply via an IPv4 UDP packet | 1 MPLS Echo Request | |||
2 Reply via an IPv4 UDP packet with Router Alert | 2 MPLS Echo Reply | |||
3 Reply via the control plane | ||||
Reply Flags are a bit vector with bit 0x1 being the Least Significant | ||||
Bit and bit 0x80 being the Most Significant Bit; the following bits | ||||
are defined: | ||||
Bit Meaning when set | The Reply Mode can take one of the following values: | |||
--- ---------------- | ||||
0x1 Downstream Mappings desired | ||||
0x2 Upstream direction pinged | ||||
Bit 0x2 is set when the reverse (upstream) direction of a bidirection | Value Meaning | |||
LSP is being tested. The details of the procedures in this case will | ----- ------- | |||
be given in a later version. | 1 Do not reply | |||
2 Reply via an IPv4 UDP packet | ||||
3 Reply via an IPv4 UDP packet with Router Alert | ||||
4 Reply via the control plane | ||||
The rest of the bits are reserved and must be zero. | An MPLS echo request with "Do not reply" may be used for one-way | |||
connectivity tests; the receiving router may log gaps in the sequence | ||||
numbers and/or maintain delay/jitter statistics. An MPLS echo | ||||
request would normally have "Reply via an IPv4 UDP packet"; if the | ||||
normal IPv4 return path is deemed unreliable, one may use "Reply via | ||||
an IPv4 UDP packet with Router Alert" (note that this requires that | ||||
all intermediate routers understand and know how to forward MPLS echo | ||||
replies) or "Reply via the control plane" (this is currently only | ||||
defined for control plane that uses RSVP). | ||||
The Return code can take one of the following values: | The Return Code is set to zero by the sender. The receiver can set | |||
it to one of the following values: | ||||
Value Meaning | Value Meaning | |||
----- ------- | ----- ------- | |||
1 Replying router is an egress for the FEC | 0 The error code is contained in the Error Code TLV | |||
2 Replying router has no mapping for the FEC | 1 Malformed echo request received | |||
3 Replying router is not one of the "Downstream Routers". | 2 One or more of the TLVs was not understood | |||
4 Replying router is one of the "Downstream Routers", | 3 Replying router is an egress for the FEC | |||
4 Replying router has no mapping for the FEC | ||||
5 Replying router is not one of the "Downstream Routers" | ||||
6 Replying router is one of the "Downstream Routers", | ||||
and its mapping for this FEC on the received interface | and its mapping for this FEC on the received interface | |||
is the given label | is the given label | |||
5 Replying router is one of the "Downstream Routers", | 7 Replying router is one of the "Downstream Routers", | |||
but its mapping for this FEC is not the given label | but its mapping for this FEC is not the given label | |||
The Return Subcode is unused at present and SHOULD be set to zero. | ||||
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 | ||||
semantics associated with this handle, although a sender may find | ||||
this useful for matching up requests with replies. | ||||
The Sequence Number is assigned by the sender of the MPLS echo | ||||
request, and can be (for example) used to detect missed replies. | ||||
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 | ||||
TimeStamp Received in an echo reply is the time-of-day (wrt 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 5, line 44 | skipping to change at page 7, line 27 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Types are defined below; Length is the length of the Value field in | Types are defined below; Length is the length of the Value field in | |||
octets. The Value field depends on the Type; it is zero padded to | octets. The Value field depends on the Type; it is zero padded to | |||
align to a four-octet boundary. | align to a four-octet boundary. | |||
Type # Value Field | Type # Value Field | |||
------ ----------- | ------ ----------- | |||
1 Target FEC Stack | 1 Target FEC Stack | |||
2 Downstream Mapping | 2 Downstream Mapping | |||
3 Pad | ||||
4 Error Code | ||||
3.1. Target FEC Stack | 3.1. Target FEC Stack | |||
A Target FEC Stack is a list of sub-TLVs. The number of elements is | A Target FEC Stack is a list of sub-TLVs. The number of elements is | |||
determined by the looking at the sub-TLV length fields. | determined by the looking at the sub-TLV length fields. | |||
Type # Length Value Field | Sub-Type # Length Value Field | |||
------ ------ ----------- | ---------- ------ ----------- | |||
1 5 IPv4 prefix | 1 5 LDP IPv4 prefix | |||
2 17 IPv6 prefix | 2 17 LDP IPv6 prefix | |||
3 16 RSVP IPv4 Session | 3 20 RSVP IPv4 Session Query | |||
4 52 RSVP IPv6 Session | 4 56 RSVP IPv6 Session Query | |||
5 6 CR-LDP LSP ID | 5 Reserved; see Appendix | |||
6 13 VPN IPv4 prefix | 6 13 VPN IPv4 prefix | |||
7 25 VPN IPv4 prefix | 7 25 VPN IPv6 prefix | |||
8 ?? L2 VPN "prefix" | 8 14 L2 VPN endpoint | |||
9 10 L2 circuit ID | ||||
Other FEC Stack 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. However, we will | corresponding to the top of the label stack, etc. | |||
assume for now that the stack consists of just one element. Also, | ||||
only the formats for FEC Types 1-5 will be described in this version. | 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 | ||||
for 192.168.1.1 (say label 1001), then to verify that label 1001 does | ||||
indeed reach an egress LSR that announced this prefix via LDP, X can | ||||
send an MPLS echo request with a FEC Stack TLV with one FEC in it, | ||||
namely of type LDP IPv4 prefix, with prefix 192.168.1.1/32, and send | ||||
the echo request with a label of 1001. | ||||
If LSR X wanted to verify that a label stack of <1001, 23456> is the | ||||
right label stack to use to reach an IP VPN prefix of 10/8 in VPN foo | ||||
on an egress LSR with loopback address 192.168.1.1 (learned via LDP), | ||||
X has two choices. X can send an MPLS echo request with a FEC Stack | ||||
TLV with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 | ||||
with the Route Distinguisher for VPN foo. Alternatively, X can send | ||||
a FEC Stack TLV with two FECs, the first of type LDP IPv4 with a | ||||
prefix of 192.168.1.1/32 and the second of type of IP VPN with a | ||||
prefix 10/8 in VPN foo. In either case, the MPLS echo request would | ||||
have a label stack of <1001, 23456>. (Note: in this example, 1001 is | ||||
the "outer" label and 23456 is the "inner" label.) | ||||
3.1.1. IPv4 Prefix | 3.1.1. 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 IPv4 prefix is in network byte | octet of prefix length in bits. The IPv4 prefix is in network byte | |||
order. | order. See [LDP] for an example of a Mapping for an IPv4 FEC. | |||
3.1.2. IPv6 Prefix | 3.1.2. IPv6 Prefix | |||
The value consists of sixteen octets of an IPv6 prefix followed by | The value consists of sixteen octets of an IPv6 prefix followed by | |||
one octet of prefix length in bits. The IPv6 prefix is in network | one octet of prefix length in bits. The IPv6 prefix is in network | |||
byte order. | byte order. | |||
3.1.3. RSVP IPv4 Session | 3.1.3. RSVP IPv4 Session | |||
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]. | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| LSP ID | 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 | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
3.1.4. RSVP IPv6 Session | 3.1.4. RSVP IPv6 Session | |||
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]. | |||
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 | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| LSP ID | Tunnel ID | | | Must Be Zero | Tunnel ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Extended Tunnel ID | | | Extended Tunnel ID | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IPv6 tunnel sender address | | | IPv6 tunnel sender address | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Must Be Zero | LSP ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
3.1.5. CR-LDP LSP ID | 3.1.5. VPN IPv4 Prefix | |||
The value consists of the LSPID of the LSP being pinged. An LSPID is | The value field consists of a Route Distinguisher, an IPv4 prefix and | |||
a four octet IPv4 address (a local address on the head end LSR) plus | a prefix length, as follows: | |||
a two octet identifier that is unique for each LSP that starts on an | ||||
LSR. | 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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Route Distinguisher | | ||||
| (8 octets) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| IPv4 prefix | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Prefix Length | Must Be Zero | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
3.1.6. VPN IPv6 Prefix | ||||
The value field consists of a Route Distinguisher, an IPv6 prefix and | ||||
a prefix length, as follows: | ||||
0 1 2 3 | ||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Route Distinguisher | | ||||
| (8 octets) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| IPv6 prefix | | ||||
| | | ||||
| | | ||||
| | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Prefix Length | Must Be Zero | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
3.1.7. L2 VPN Endpoint | ||||
The value field consists of a Route Distinguisher (8 octets), the | ||||
sender (of the ping)'s CE ID (2 octets), the receiver's CE ID (2 | ||||
octets), and an encapsulation type (2 octets), formatted as follows: | ||||
0 1 2 3 | ||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Route Distinguisher | | ||||
| (8 octets) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sender's CE ID | Receiver's CE ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Encapsulation Type | Must Be Zero | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
3.1.8. L2 Circuit ID | ||||
The value field consists of a remote PE address (the address of the | ||||
targetted LDP session), a VC ID and an encapsulation type, as | ||||
follows: | ||||
0 1 2 3 | ||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Remote PE Address | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| VC ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Encapsulation Type | Must Be Zero | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
3.2. Downstream Mapping | 3.2. Downstream Mapping | |||
The Downstream Mapping is an optional TLV in an echo request. The | The Downstream Mapping is an optional TLV in an echo request. The | |||
Length is 4 + 4*N, where N is the number of Downstream Labels. The | Length is 12 + 4*N octets, where N is the number of Downstream | |||
Value of a Downstream Mapping has the following format: | Labels. The Value of a Downstream 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Downstream IPv4 Router ID | | | Downstream IPv4 Router ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| MTU | Address Type | Reserved | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Interface Address | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Downstream Label | Protocol | | | Downstream Label | Protocol | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
. . | . . | |||
. . | . . | |||
. . | . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Downstream Label | Protocol | | | Downstream Label | Protocol | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
The MTU is the largest MPLS frame (including label stack) that fits | ||||
on the interface to the Downstream LSR. The Address Type is one of: | ||||
Type # Address Type | ||||
------ ------------ | ||||
1 IPv4 | ||||
2 Unnumbered | ||||
'Protocol' is taken from the following table: | 'Protocol' is taken from the following table: | |||
Protocol # Signaling Protocol | Protocol # Signaling Protocol | |||
---------- ------------------ | ---------- ------------------ | |||
0 Unknown | 0 Unknown | |||
1 Static | 1 Static | |||
2 BGP | 2 BGP | |||
3 LDP | 3 LDP | |||
4 RSVP-TE | 4 RSVP-TE | |||
5 CR-LDP | 5 Reserved; see Appendix | |||
The notion of "downstream router" should be explained. Consider an | The notion of "downstream router" should be explained. Consider an | |||
LSR X. If a packet with outermost label L and TTL n>1 arrived at X | LSR X. If a packet with outermost label L and TTL n>1 arrived at X | |||
on interface I, X must be able to compute which LSRs could receive | on interface I, X must be able to compute which LSRs could receive | |||
the packet with TTL=n, and what label they would see. (It is outside | the packet with TTL=n+1, and what label they would see. (It is | |||
the scope of this document to specify how this computation may be | outside the scope of this document to specify how this computation | |||
done.) The set of these LSRs are the downstream routers (and their | may be done.) The set of these LSRs are the downstream routers (and | |||
corresponding labels) for X with respect to L. | their corresponding labels) for X with respect to L. | |||
The case where X is the LSR originating the echo request is a special | The case where X is the LSR originating the echo request is a special | |||
case. X needs to figure out what LSRs would receive a labelled | case. X needs to figure out what LSRs would receive a labelled | |||
packet with TTL=1 when X tries to send a packet to the FEC Stack that | packet with TTL=1 when X tries to send a packet to the FEC Stack that | |||
is being pinged. | is being pinged. | |||
4. Theory of Operation | 3.3. Pad TLV | |||
4.1. MPLS Echo Request | The value part of the Pad TLV contains a variable number (>= 1) of | |||
octets. The first octet takes values from the following table; all | ||||
the other octets (if any) are ignored. The receiver SHOULD verify | ||||
that the TLV is received in its entirety, but otherwise ignores the | ||||
contents of this TLV, apart from the first octet. | ||||
An MPLS echo request is a labeled UDP packet sent to the well-known | Value Meaning | |||
port for MPLS ping [UDP port # 3503 assigned by IANA], with | ----- ------- | |||
destination IP address set to the ALL-ROUTERS multicast address | 1 Drop Pad TLV from reply | |||
(224.0.0.2). The source IP address is set to a routable address of | 2 Copy Pad TLV to reply | |||
the sender; the source port identifies the sending process. The IP | 3-255 Reserved for future use | |||
TTL in the UDP packet is set to 1. | ||||
An MPLS echo request MUST have a FEC Stack TLV. Also, the Reply Mode | 3.4. Error Code | |||
must be set to the desired reply mode; the Return Code is set to zero | ||||
and ignored on receipt. | The Error Code TLV is currently not defined; its purpose is to | |||
provide a mechanism for a more elaborate error reporting structure, | ||||
should the reason arise. | ||||
4. Theory of Operation | ||||
4.1. Sending an MPLS Echo Request | ||||
An MPLS echo request is a (possibly) labelled UDP packet. The IP | ||||
header is set as follows: the source IP address is a routable address | ||||
of the sender; the destination IP address is a (randomly chosen) | ||||
address from 127/8; the IP TTL is set to 1. The source UDP port is | ||||
chosen by the sender; the destination UDP port is set to 3503 | ||||
(assigned by IANA for MPLS echo requests). If the echo request is | ||||
labelled, the MPLS TTL on all the labels except the outermost should | ||||
be set to 1. | ||||
In "ping" mode (end-to-end connectivity check), the TTL in the | In "ping" mode (end-to-end connectivity check), the TTL in the | |||
outermost label is set to 255. | outermost label is set to 255. In "traceroute" mode (fault isolation | |||
mode), the TTL is set successively to 1, 2, .... | ||||
In "traceroute" mode (fault isolation mode), the TTL is set | The sender chooses a Sender's Handle, and a Sequence Number. When | |||
successively to 1, 2, .... | sending subsequent MPLS echo requests, the sender SHOULD increment | |||
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 | ||||
chance of arrival of at least one packet with that sequence number. | ||||
The TimeStamp Sent is set to the time-of-day (in seconds and | ||||
microseconds) that the echo request is sent. The TimeStamp Received | ||||
is set to zero. | ||||
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 | ||||
are set to zero. | ||||
In the "traceroute" mode, the echo request SHOULD contain one or more | In the "traceroute" mode, the echo request SHOULD contain one or more | |||
Downstream Mapping TLVs. For TTL=1, all the downstream routers (and | Downstream Mapping TLVs. For TTL=1, all the downstream routers (and | |||
corresponding labels) for the sender with respect to the FEC Stack | corresponding labels) for the sender with respect to the FEC Stack | |||
being pinged SHOULD be sent in the echo request. For n>1, the | being pinged SHOULD be sent in the echo request. For n>1, the | |||
Downstream Mapping TLVs from the echo reply for TTL=(n-1) are copied | Downstream Mapping TLVs from the echo reply for TTL=(n-1) are copied | |||
to the echo request with TTL=n. | to the echo request with TTL=n. | |||
4.2. MPLS Echo Reply | 4.2. Receiving an MPLS Echo Request | |||
An LSR L that receives an MPLS echo request first parses the packet | ||||
to ensure that it is a well-formed packet, and that the TLVs are | ||||
understood. If not, L SHOULD send an MPLS echo reply with the | ||||
Return Code set to "Malformed echo request received" or "TLV not | ||||
understood" (as appropriate), and the Subcode set to the appropriate | ||||
value. | ||||
If the echo request is good, L then checks whether it is a valid | ||||
transit or egress LSR for the FEC in the echo request. If not, L MAY | ||||
log this fact. | ||||
If the echo request contains a Downstream Mapping TLV, L MUST further | ||||
check whether its Router ID matches one of the Downstream IPv4 Router | ||||
IDs; and if so, whether the given Downstream Label is in fact the | ||||
label that L sent as its mapping for the FEC. For an RSVP FEC, the | ||||
downstream label is the label that L sent in its Resv message. The | ||||
result of the checks in the previous and this paragraph are captured | ||||
in the Return Code/Subcode. | ||||
If the echo request has a Reply Mode that wants a reply, L uses the | ||||
procedure in the next subsection to send the echo reply. | ||||
4.3. 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 the Router ID of | to an MPLS echo request. The source IP address is a routable address | |||
the replier; the source port is the well-known UDP port for MPLS | of the replier; the source port is the well-known UDP port for MPLS | |||
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 | |||
the Router Alert IP option. | the Router Alert IP option. | |||
The format of the echo reply is the same as the echo request. The | The format of the echo reply is the same as the echo request. The | |||
Sequence Number is copied from the echo request; the TimeStamp is set | Sender's Handle, the Sequence Number and TimeStamp Sent are copied | |||
to the time-of-day that the echo request is received (note that this | from the echo request; the TimeStamp Received is set to the time-of- | |||
information is most useful if the time-of-day clocks on the requestor | day that the echo request is received (note that this information is | |||
and the replier are synchronized). The FEC Stack TLV from the echo | most useful if the time-of-day clocks on the requestor and the | |||
request is copied to the reply. | replier are synchronized). The FEC Stack TLV from the echo request | |||
MAY be copied to the reply. | ||||
The replier MUST fill in the Return Code. This is set based on | The replier MUST fill in the Return Code and Subcode, as determined | |||
whether the replier has a mapping for the FEC, and whether it is an | in the previous subsection. | |||
egress for that FEC. Note that 'having a mapping' for an RSVP FEC | ||||
means that the replier is a transit LSR for the RSVP LSP defined by | If the echo request contains a Pad TLV, the replier MUST interpret | |||
the FEC. | the first octet for instructions regarding how to reply. | |||
If the echo request contains a Downstream Mapping TLV, the replier | If the echo request contains a Downstream Mapping TLV, the replier | |||
MUST further check whether its Router ID matches one of the | SHOULD compute its downstream routers and corresponding labels for | |||
Downstream IPv4 Router IDs; and if so, whether the given Downstream | the incoming label, and add Downstream Mapping TLVs for each one to | |||
Label is in fact the label that the replier sent as its mapping for | the echo reply it sends back. | |||
the FEC. For an RSVP FEC, the downstream label is the label that the | ||||
replier sent in its Resv message. The result of these checks are | ||||
captured in the Return Code. | ||||
If the flag requesting Downstream Mapping TLVs is set in the Reply | 4.4. Receiving an MPLS Echo Reply | |||
Flags, the replier SHOULD compute its downstream routers and | ||||
corresponding labels for the incoming label, and add Downstream | ||||
Mapping TLVs for each one to the echo reply it sends back. | ||||
4.3. Non-compliant Routers | 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 | ||||
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 | ||||
had previously sent, using the destination UDP port and the Sender's | ||||
Handle. If no match is found, then X jettisons the Echo Reply; | ||||
otherwise, it checks the Sequence Number to see if it matches. Gaps | ||||
in 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 | ||||
traceroute further, it SHOULD copy the Downstream Mappings into its | ||||
next Echo Request (with TTL incremented by one). | ||||
4.5. Non-compliant Routers | ||||
If the egress for the FEC Stack being pinged does not support MPLS | If the egress for the FEC Stack being pinged does not support MPLS | |||
ping, then no reply will be sent, resulting in possible "false | ping, then no reply will be sent, resulting in possible "false | |||
negatives". If in "traceroute" mode, a transit LSR does not support | negatives". If in "traceroute" mode, a transit LSR does not support | |||
MPLS ping, then no reply will be forthcoming from that LSR for some | MPLS ping, then no reply will be forthcoming from that LSR for some | |||
TTL, say n. The LSR originating the echo request SHOULD try sending | TTL, say n. The LSR originating the echo request SHOULD try sending | |||
the echo request with TTL=n+1, n+2, ..., n+k in the hope that some | the echo request with TTL=n+1, n+2, ..., n+k in the hope that some | |||
transit LSR further downstream may support MPLS echo requests and | transit LSR further downstream may support MPLS echo requests and | |||
reply. In such a case, the echo request for TTL>n MUST NOT have | reply. In such a case, the echo request for TTL>n MUST NOT have | |||
Downstream Mapping TLVs, until a reply is received with a Downstream | Downstream Mapping TLVs, until a reply is received with a Downstream | |||
skipping to change at page 11, line 15 | skipping to change at page 16, line 11 | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Sequence Number | | | Sequence Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| TimeStamp (seconds) | | | TimeStamp (seconds) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| TimeStamp (microseconds) | | | TimeStamp (microseconds) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| UDP Source Port | Return Code | Must be zero | | | UDP Source Port | Return Code | Return Subcode| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
The Sequence Number is copied from the Sequence Number of the echo | The Sequence Number is copied from the Sequence Number of the echo | |||
request. The TimeStamp is set to the time the echo request is | request. The TimeStamp is set to the time the echo request is | |||
received. The UDP Source Port is copied from the UDP source port of | received. The UDP Source Port is copied from the UDP source port of | |||
the MPLS echo request. The FEC is implied by the Session and the | the MPLS echo request. The FEC is implied by the Session and the | |||
Sender Template Objects. | Sender Template Objects. | |||
5.2. Operation | 5.2. Operation | |||
skipping to change at page 11, line 37 | skipping to change at page 16, line 33 | |||
control plane" we mean "the RSVP-TE component of the control plane". | control plane" we mean "the RSVP-TE component of the control plane". | |||
Consider an LSP between an ingress LSR and an egress LSR spanning | Consider an LSP between an ingress LSR and an egress LSR spanning | |||
multiple LSR hops. | multiple LSR hops. | |||
5.3. Procedures at the ingress LSR | 5.3. Procedures at the ingress LSR | |||
One must ensure before setting the Reply Mode to "reply via the | One must ensure before setting the Reply Mode to "reply via the | |||
control plane" that the egress LSR supports this feature. | control plane" that the egress LSR supports this feature. | |||
The ingress LSR, say X, selects a unique UDP source port for its MPLS | The ingress LSR, say X, builds an MPLS echo request as in section | |||
ping. X also sets the FEC Stack TLV Type to RSVP IPv4 (IPv6), and | "Sending an MPLS Echo Request". The FEC Type must be an RVSP Session | |||
copies the SESSION and SENDER_TEMPLATE into the appropriate fields of | Query. X also sets the Reply Mode to "reply via the control plane". | |||
the value field. Finally, X sets the Reply Mode to "reply via the | ||||
control plane". | ||||
If X does not receive an Resv message from the egress LSR that | If X does not receive an Resv message from the egress LSR that | |||
contains an LSP_ECHO object within some period of time, it declares | contains an LSP_ECHO object within some period of time, it declares | |||
the LSP as "down". At this point, the ingress LSR may apply the | the LSP as "down". At this point, the ingress LSR may apply the | |||
necessary procedures to fix the LSP. These may include generating a | necessary procedures to fix the LSP. These may include generating a | |||
message to network management, tearing-down and re-building the LSP, | message to network management, tearing-down and re-building the LSP, | |||
and/or rerouting user traffic to a backup LSP. | and/or rerouting user traffic to a backup LSP. | |||
To test an LSP that carries non-IP traffic, before injecting ICMP and | To test an LSP that carries non-IP traffic, before injecting ICMP and | |||
MPLS ping messages into the LSP, the IPv4 Explicit NULL label should | MPLS ping messages into the LSP, the IPv4 Explicit NULL label should | |||
skipping to change at page 12, line 33 | skipping to change at page 17, line 28 | |||
At intermediate LSRs, normal RSVP processing procedures will cause | At intermediate LSRs, normal RSVP processing procedures will cause | |||
the LSP_ECHO object to be forwarded as RSVP messages are refreshed. | the LSP_ECHO object to be forwarded as RSVP messages are refreshed. | |||
At the LSR's that support MPLS ping the Resv messages that carry the | At the LSR's that support MPLS ping the Resv messages that carry the | |||
LSP_ECHO object MUST be delivered upstream immediately. | LSP_ECHO object MUST be delivered upstream immediately. | |||
Note that an intermediate LSR using RSVP refresh reduction [RSVP- | Note that an intermediate LSR using RSVP refresh reduction [RSVP- | |||
REFRESH], the new or changed LSP_ECHO object will cause the LSR to | REFRESH], the new or changed LSP_ECHO object will cause the LSR to | |||
classify the RSVP message as a trigger message. | classify the RSVP message as a trigger message. | |||
6. Security Considerations | 6. Normative References | |||
The security considerations pertaining to the original RSVP protocol | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |||
remain relevant. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
7. Intellectual Property Considerations | [LABEL-STACKING] Rosen, E., et al, "MPLS Label Stack Encoding", RFC | |||
3032, January 2001. | ||||
Juniper Networks, Inc. is seeking patent protection on technology | [RSVP] Braden, R. (Editor), et al, "Resource ReSerVation protocol | |||
described in this Internet-Draft. If technology in this Internet- | (RSVP) -- Version 1 Functional Specification," RFC 2205, | |||
Draft is adopted as a standard, Juniper Networks agrees to license, | September 1997. | |||
on reasonable and non-discriminatory terms, any patent rights it | ||||
obtains covering such technology to the extent necessary to comply | ||||
with the standard. | ||||
8. Acknowledgments | [RSVP-REFRESH] Berger, L., et al, "RSVP Refresh Overhead Reduction | |||
Extensions", RFC 2961, April 2001. | ||||
This is the outcome of many discussions among many people, that also | [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP | |||
include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa Gan, | tunnels", RFC 3209, December 2001. | |||
Brook Bailey and Eric Rosen. | ||||
9. References | 7. Informative References | |||
[ICMP] J. Postel, "Internet Control Message Protocol", RFC792. | [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792. | |||
[RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) | [LDP] Andersson, L., et al, "LDP Specification", RFC 3036, January | |||
-- version 1 functional specification," RFC2205. | 2001. | |||
[RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP | 8. Security Considerations | |||
tunnels" Internet Draft. | ||||
[LABEL-STACKING] E. Rosen, et al, "MPLS Label Stack Encoding", | There are at least two approaches to attacking LSRs using the | |||
RFC3032. | mechanisms defined here. One is a Denial of Service attack, by | |||
sending MPLS echo requests/replies to LSRs and thereby increasing | ||||
their workload. The other is obfuscating the state of the MPLS data | ||||
plane liveness by spoofing, hijacking, replaying or otherwise | ||||
tampering with MPLS echo requests and replies. | ||||
[RSVP-REFRESH] L. Berger, et al, "RSVP Refresh Overhead Reduction | Authentication will help reduce the number of seemingly valid MPLS | |||
Extensions", RFC2961. | echo requests, and thus cut down the Denial of Service attacks; | |||
beyond that, each LSR must protect itself. | ||||
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an | Authentication sufficiently addresses spoofing, replay and most | |||
IANA Considerations Section in RFCs", RFC 2434. | tampering attacks; one hopes to use some mechanism devised or | |||
suggested by the RPSec WG. It is not clear how to prevent hijacking | ||||
(non-delivery) of echo requests or replies; however, if these | ||||
messages are indeed hijacked, MPLS ping will report that the data | ||||
plane isn't working as it should. | ||||
10. Author Information | 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 | ||||
the MPLS data plane may be considered confidential by some. | ||||
9. IANA Considerations | ||||
(To be filled in a later revision) | ||||
10. Acknowledgments | ||||
This document is the outcome of many discussions among many people, | ||||
that include Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa | ||||
Gan, Brook Bailey, Eric Rosen and Ina Minei. | ||||
11. Appendix | ||||
This appendix specifies non-normative aspects of detecting MPLS data | ||||
plane liveness. | ||||
11.1. CR-LDP FEC | ||||
This section describes how a CR-LDP FEC can be included in an Echo | ||||
Request using the following FEC subtype: | ||||
Sub-Type # Length Value Field | ||||
---------- ------ ----------- | ||||
5 6 CR-LDP LSP ID | ||||
The value consists of the LSPID of the LSP being pinged. An LSPID is | ||||
a four octet IPv4 address (a local address on the ingress LSR, for | ||||
example, the Router ID) plus a two octet identifier that is unique | ||||
per LSP on a given ingress LSR. | ||||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Ingress LSR Router ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Must Be Zero | LSP ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
11.2. Downstream Mapping for CR-LDP | ||||
If a label in a Downstream Mapping was learned via CR-LDP, the | ||||
Protocol field in the Mapping TLV can use the following entry: | ||||
Protocol # Signaling Protocol | ||||
---------- ------------------ | ||||
5 CR-LDP | ||||
12. Authors' Addresses | ||||
Kireeti Kompella | Kireeti Kompella | |||
Ping Pan | ||||
Nischal Sheth | Nischal Sheth | |||
Juniper Networks | Juniper Networks | |||
1194 N.Mathilda Ave | 1194 N.Mathilda Ave | |||
Sunnyvale, CA 94089 | Sunnyvale, CA 94089 | |||
e-mail: kireeti@juniper.net | e-mail: kireeti@juniper.net | |||
e-mail: pingpan@juniper.net | ||||
e-mail: nsheth@juniper.net | e-mail: nsheth@juniper.net | |||
phone: 408.745.2000 | ||||
Ping Pan | ||||
Ciena | ||||
10480 Ridgeview Court | ||||
Cupertino, CA 95014 | ||||
e-mail: ppan@ciena.com | ||||
phone: +1 408.366.4700 | ||||
Dave Cooper | Dave Cooper | |||
Global Crossing | Global Crossing | |||
960 Hamlin Court | 960 Hamlin Court | |||
Sunnyvale, CA 94089 | Sunnyvale, CA 94089 | |||
email: dcooper@gblx.net | email: dcooper@gblx.net | |||
phone: 916.415.0437 | phone: +1 916.415.0437 | |||
George Swallow | George Swallow | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
250 Apollo Drive | 250 Apollo Drive | |||
Chelmsford, MA 01824 | Chelmsford, MA 01824 | |||
e-mail: swallow@cisco.com | e-mail: swallow@cisco.com | |||
phone: 978.244.8143 | phone: +1 978.497.8143 | |||
Sanjay Wadhwa | Sanjay Wadhwa | |||
Unisphere Networks, Inc. | Juniper Networks | |||
10 Technology Park Drive | 10 Technology Park Drive | |||
Westford, MA 01886-3146 | Westford, MA 01886-3146 | |||
email: swadhwa@unispherenetworks.com | email: swadhwa@unispherenetworks.com | |||
phone: 978.589.0697 | phone: +1 978.589.0697 | |||
Ronald P. Bonica | Ronald P. Bonica | |||
WorldCom | WorldCom | |||
22001 Loudoun County Pkwy | 22001 Loudoun County Pkwy | |||
Ashburn, Virginia, 20147 | Ashburn, Virginia, 20147 | |||
email: ronald.p.bonica@wcom.com | email: ronald.p.bonica@wcom.com | |||
phone: 703.886.1681 | phone: +1 703.886.1681 | |||
13. Intellectual Property Rights Notices | ||||
The IETF takes no position regarding the validity or scope of any | ||||
intellectual property or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology described in | ||||
this document or the extent to which any license under such rights | ||||
might or might not be available; neither does it represent that it | ||||
has made any effort to identify any such rights. Information on the | ||||
IETF's procedures with respect to rights in standards-track and | ||||
standards-related documentation can be found in BCP-11. Copies of | ||||
claims of rights made available for publication and any assurances of | ||||
licenses to be made available, or the result of an attempt made to | ||||
obtain a general license or permission for the use of such | ||||
proprietary rights by implementors or users of this specification can | ||||
be obtained from the IETF Secretariat. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights which may cover technology that may be required to practice | ||||
this standard. Please address the information to the IETF Executive | ||||
Director. | ||||
Full Copyright Statement | ||||
Copyright (C) The Internet Society (2002). All Rights Reserved. | ||||
This document and translations of it may be copied and furnished to | ||||
others, and derivative works that comment on or otherwise explain it | ||||
or assist in its implmentation may be prepared, copied, published and | ||||
distributed, in whole or in part, without restriction of any kind, | ||||
provided that the above copyright notice and this paragraph are | ||||
included on all such copies and derivative works. However, this | ||||
document itself may not be modified in any way, such as by removing | ||||
the copyright notice or references to the Internet Society or other | ||||
Internet organizations, except as needed for the purpose of | ||||
developing Internet standards in which case the procedures for | ||||
copyrights defined in the Internet Standards process must be | ||||
followed, or as required to translate it into languages other than | ||||
English. | ||||
The limited permissions granted above are perpetual and will not be | ||||
revoked by the Internet Society or its successors or assigns. | ||||
This document and the information contained herein is provided on an | ||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | ||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | ||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | ||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |