draft-ietf-mpls-lsp-ping-02.txt | draft-ietf-mpls-lsp-ping-03.txt | |||
---|---|---|---|---|
Network Working Group K. Kompella (Juniper) | Network Working Group K. Kompella (Juniper) | |||
Internet Draft P. Pan (Ciena) | Internet Draft P. Pan (Ciena) | |||
draft-ietf-mpls-lsp-ping-02.txt N. Sheth (Juniper) | draft-ietf-mpls-lsp-ping-03.txt N. Sheth (Juniper) | |||
Category: Standards Track D. Cooper (Global Crossing) | Category: Standards Track D. Cooper (Global Crossing) | |||
Expires: September 2003 G. Swallow (Cisco) | Expires: December 2003 G. Swallow (Cisco) | |||
S. Wadhwa (Juniper) | S. Wadhwa (Juniper) | |||
R. Bonica (WorldCom) | R. Bonica (WorldCom) | |||
March 2003 | June 2003 | |||
Detecting MPLS Data Plane Liveness | Detecting MPLS Data Plane Failures | |||
*** DRAFT *** | *** DRAFT *** | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
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 14 | skipping to change at page 2, line 14 | |||
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. | |||
Sub-IP ID Summary | Changes since last revision | |||
(This section to be removed before publication.) | (This section to be removed before publication.) | |||
(See Abstract above.) | - Changed title to "Detecting MPLS Data Plane Failures" | |||
- removed section 5 "Reliable Reply Path" | ||||
RELATED DOCUMENTS | - filled in IANA section | |||
- added new top level TLV for Vendor Enterprise Code | ||||
May be found in the "references" section. | - Clarified Downstream Router ID and Downstream Interface Address | |||
- Clarified receiving procedure | ||||
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK | - Example for multipath operation | |||
Fits in the MPLS box. | ||||
WHY IS IT TARGETED AT THIS WG | ||||
MPLS WG is currently looking at MPLS-specific error detection and | Issues | |||
recovery mechanisms. The mechanisms proposed here are for packet- | ||||
based MPLS LSPs, which is why the MPLS WG is targeted. | ||||
JUSTIFICATION | (This section to be removed before publication.) | |||
The WG should consider this document, as it allows network operators | - Question: use two bits from the TLV space to indicate | |||
to detect MPLS LSP data plane failures in the network. This type of | - Ignore TLV if not understood | |||
failures have occurred, and are a source of concern to operators | - Reflect TLV in reply | |||
implementing MPLS networks. | - Tweak error codes? Add stack depth? | |||
- More multipath stuff? | ||||
1. Introduction | 1. Introduction | |||
This document describes a simple and efficient mechanism that can be | This document describes a simple and efficient mechanism that can be | |||
used to detect data plane failures in MPLS LSPs. There are two parts | used to detect data plane failures in MPLS LSPs. There are two parts | |||
to this document: information carried in an MPLS "echo request" and | to this document: information carried in an MPLS "echo request" and | |||
"echo reply"; and mechanisms for transporting the echo reply. The | "echo reply"; and mechanisms for transporting the echo reply. The | |||
first part aims at providing enough information to check correct | first part aims at providing enough information to check correct | |||
operation of the data plane, as well as a mechanism to verify the | operation of the data plane, as well as a mechanism to verify the | |||
data plane against the control plane, and thereby localize faults. | data plane against the control plane, and thereby localize faults. | |||
skipping to change at page 3, line 45 | skipping to change at page 4, line 5 | |||
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, MPLS ping operation, and a reliable | request/reply packet format, MPLS 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. | |||
The last section (reliable return path for RSVP LSPs) may be removed | The last section (reliable return path for RSVP LSPs) may be removed | |||
in a future revision. | in a future revision. | |||
1.3. Changes since last revision | ||||
(This section to be removed before publication.) | ||||
- Clarified definition of downstream router/interface. | ||||
- Added text for multipath (mostly just taken from Curtis) | ||||
- Mandated the use of Router Alert for sending echo requests | ||||
- If reply mode says IPv4 with router alert, and the reply is | ||||
labeled, the top label MUST be the router alert label | ||||
- Expanded the Theory of Operation, and added a section on ECMP | ||||
- Expanded checks on receipt of echo requests, per email on list | ||||
1.4. Issues remaining | ||||
(This section to be removed before publication.) | ||||
- Monitoring mode | ||||
- Finalize ECMP format and semantics | ||||
- Keep or remove replies via control plane? | ||||
- Normalize error codes | ||||
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 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: | |||
skipping to change at page 6, line 17 | skipping to change at page 6, line 10 | |||
1 MPLS Echo Request | 1 MPLS Echo Request | |||
2 MPLS Echo Reply | 2 MPLS Echo Reply | |||
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 UDP packet | 2 Reply via an IPv4 UDP packet | |||
3 Reply via an IPv4 UDP packet with Router Alert | 3 Reply via an IPv4 UDP packet with Router Alert | |||
4 Reply via the control plane | ||||
An MPLS echo request with "Do not reply" may be used for one-way | 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 | connectivity tests; the receiving router may log gaps in the sequence | |||
numbers and/or maintain delay/jitter statistics. An MPLS echo | numbers and/or maintain delay/jitter statistics. An MPLS echo | |||
request would normally have "Reply via an IPv4 UDP packet"; if the | request would normally have "Reply via an IPv4 UDP packet"; if the | |||
normal IPv4 return path is deemed unreliable, one may use "Reply via | normal IPv4 return path is deemed unreliable, one may use "Reply via | |||
an IPv4 UDP packet with Router Alert" (note that this requires that | an IPv4 UDP packet with Router Alert" (note that this requires that | |||
all intermediate routers understand and know how to forward MPLS echo | all intermediate routers understand and know how to forward MPLS echo | |||
replies) or "Reply via the control plane" (this is currently only | replies). | |||
defined for control plane that uses RSVP). | ||||
The Return Code is set to zero by the sender. The receiver can set | The Return Code is set to zero by the sender. The receiver can set | |||
it to one of the following values: | it to one of the following values: | |||
Value Meaning | Value Meaning | |||
----- ------- | ----- ------- | |||
0 The error code is contained in the Error Code TLV | 0 The error code is contained in the Error Code TLV | |||
1 Malformed echo request received | 1 Malformed echo request received | |||
2 One or more of the TLVs was not understood | 2 One or more of the TLVs was not understood | |||
3 Replying router is an egress for the FEC | 3 Replying router is an egress for the FEC | |||
skipping to change at page 7, line 37 | 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 | 3 Pad | |||
4 Error Code | 4 Error Code | |||
5 Vendor Enterprise 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. | |||
Sub-Type # Length Value Field | Sub-Type # Length Value Field | |||
---------- ------ ----------- | ---------- ------ ----------- | |||
1 5 LDP IPv4 prefix | 1 5 LDP IPv4 prefix | |||
2 17 LDP IPv6 prefix | 2 17 LDP IPv6 prefix | |||
skipping to change at page 8, line 19 | skipping to change at page 8, line 10 | |||
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 | 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 | 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, | 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 | namely of type LDP IPv4 prefix, with prefix 192.168.1.1/32, and send | |||
the echo request with a label of 1001. | the echo request with a label of 1001. | |||
If 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 an IP VPN prefix of 10/8 in VPN foo | right label stack to use to reach a VPN IPv4 prefix of 10/8 in VPN | |||
on an egress LSR with loopback address 192.168.1.1 (learned via LDP), | foo. Say further that LSR Y with loopback address 192.168.1.1 | |||
X has two choices. X can send an MPLS echo request with a FEC Stack | announced prefix 10/8 with Route Distinguisher RD-foo-Y (which may in | |||
TLV with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 | general be different from the Route Distinguisher that LSR X uses in | |||
with the Route Distinguisher for VPN foo. Alternatively, X can send | its own advertisements for VPN foo), label 23456 and BGP nexthop | |||
a FEC Stack TLV with two FECs, the first of type LDP IPv4 with a | 192.168.1.1. Finally, suppose that LSR X receives a label binding of | |||
prefix of 192.168.1.1/32 and the second of type of IP VPN with a | 1001 for 192.168.1.1 via LDP. X has two choices in sending an MPLS | |||
prefix 10/8 in VPN foo. In either case, the MPLS echo request would | echo request: X can send an MPLS echo request with a FEC Stack TLV | |||
have a label stack of <1001, 23456>. (Note: in this example, 1001 is | with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 and a | |||
the "outer" label and 23456 is the "inner" label.) | Route Distinguisher of RD-foo-Y. 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 | ||||
with Route Distinguisher of RD-foo-Y. 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. LDP IPv4 Prefix | 3.1.1. LDP 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. See [LDP] for an example of a Mapping for an IPv4 FEC. | order. See [LDP] for an example of a Mapping for an IPv4 FEC. | |||
3.1.2. LDP IPv6 Prefix | 3.1.2. LDP 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 | |||
skipping to change at page 9, line 44 | skipping to change at page 9, line 40 | |||
| IPv6 tunnel sender address | | | IPv6 tunnel sender address | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Must Be Zero | LSP ID | | | Must Be Zero | LSP ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
3.1.5. VPN IPv4 Prefix | 3.1.5. VPN IPv4 Prefix | |||
The value field consists of a Route Distinguisher, an IPv4 prefix and | The value field consists of the Route Distinguisher advertised with | |||
a prefix length, as follows: | the VPN IPv4 prefix, the IPv4 prefix 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.1.6. VPN IPv6 Prefix | 3.1.6. VPN IPv6 Prefix | |||
The value field consists of a Route Distinguisher, an IPv6 prefix and | The value field consists of the Route Distinguisher advertised with | |||
a prefix length, as follows: | the VPN IPv6 prefix, the IPv6 prefix 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 | | |||
| | | | | | |||
| | | | | | |||
skipping to change at page 11, line 18 | skipping to change at page 11, line 13 | |||
| Remote PE Address | | | Remote PE Address | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| VC ID | | | VC ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Encapsulation Type | Must Be Zero | | | 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 12 + 4*N octets, where N is the number of Downstream | Length is 16 + 4*M + 4*N octets, where M is the Multipath Length, and | |||
Labels. The Value of a Downstream Mapping has the following format: | N is the number of Downstream Labels. The Value field 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 Address | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| MTU | Address Type | DS Index | | | MTU | Address Type | DS Index | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Downstream Interface Address | | | Downstream Interface Address | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Hash Key Type | Depth Limit | Multipath Length | | | Hash Key Type | Depth Limit | No of Multipaths | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IP Address or Next Label | | | IP Address or Next Label | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
. . | . . | |||
. (more IP Addresses or Next Labels) . | . (more IP Addresses or Next Labels) . | |||
. . | . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Downstream Label | Protocol | | | Downstream Label | Protocol | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
. . | . . | |||
. . | . . | |||
. . | . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Downstream Label | Protocol | | | Downstream Label | Protocol | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
If the interface to the downstream LSR is numbered, then the | ||||
Downstream IPv4 Address can either be the downstream LSR's Router ID | ||||
or the interface address of the downstream LSR. In this case, the | ||||
Address Type is set to IPv4 and the Downstream Interface Address is | ||||
set to the downstream LSR's interface address. If the interface to | ||||
the downstream LSR is unnumbered, the Downstream IPv4 Address MUST be | ||||
the downstream LSR's Router ID, and the Address Type MUST be | ||||
Unnumbered, and the Downstream Interface Address MUST be the index | ||||
assigned by the upstream LSR to the interface. | ||||
The MTU is the largest MPLS frame (including label stack) that fits | The MTU is the largest MPLS frame (including label stack) that fits | |||
on the interface to the Downstream LSR. The Downstream Interface | on the interface to the Downstream LSR. The Downstream Interface | |||
Address Type is one of: | Address Type is one of: | |||
Type # Address Type | Type # Address Type | |||
------ ------------ | ------ ------------ | |||
1 IPv4 | 1 IPv4 | |||
2 Unnumbered | 2 Unnumbered | |||
'Protocol' is taken from the following table: | 'Protocol' is taken from the following table: | |||
skipping to change at page 12, line 40 | skipping to change at page 12, line 47 | |||
the incoming label L may be swapped with a label stack.) | the incoming label L may be swapped with a label stack.) | |||
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 the MPLS echo | case. X needs to figure out what LSRs would receive the MPLS echo | |||
request for a given FEC Stack that X originates with TTL=1. | request for a given FEC Stack that X originates with TTL=1. | |||
The set of downstream routers at X may be alternative paths (see the | The set of downstream routers at X may be alternative paths (see the | |||
discussion below on ECMP) or simultaneous paths (e.g., for MPLS | discussion below on ECMP) or simultaneous paths (e.g., for MPLS | |||
multicast). In the former case, the Multipath sub-field is used as a | multicast). In the former case, the Multipath sub-field is used as a | |||
hint to the sender as to how it may influence the choice of these | hint to the sender as to how it may influence the choice of these | |||
alternatives. The Multipath Length is the total length of the | alternatives. The "No of Multipaths" is the number of IP | |||
Multipath field (i.e., 4 + 4*M, where M is the number of IP | Address/Next Label fields. The Hash Key Type is taken from the | |||
Address/Next Label fields). The Hash Key Type is taken from the | ||||
following table: | following table: | |||
Hash Key Type IP Address or Next Label | Hash Key Type IP Address or Next Label | |||
-------------------- ------------------------ | -------------------- ------------------------ | |||
0 no multipath (nothing; M = 0) | 0 no multipath (nothing; M = 0) | |||
1 label M labels | 1 label M labels | |||
2 IP address M IP addresses | 2 IP address M IP addresses | |||
3 label range M/2 low/high label pairs | 3 label range M/2 low/high label pairs | |||
4 IP address range M/2 low/high address pairs | 4 IP address range M/2 low/high address pairs | |||
5 no more labels (nothing; M = 0) | 5 no more labels (nothing; M = 0) | |||
skipping to change at page 13, line 19 | skipping to change at page 13, line 24 | |||
maximum number of labels considered in the hash; this SHOULD be set | maximum number of labels considered in the hash; this SHOULD be set | |||
to zero if unspecified or unlimited. | to zero if unspecified or unlimited. | |||
IP Address or Next Label is an IP address from the range 127/8 or an | IP Address or Next Label is an IP address from the range 127/8 or an | |||
next label which will exercise this particular path. | next label which will exercise this particular path. | |||
The semantics of the Hash Key Type and IP Address/Next Label are as | The semantics of the Hash Key Type and IP Address/Next Label are as | |||
follows: | follows: | |||
type 1 - a list of single labels is provided, any one of which | type 1 - a list of single labels is provided, any one of which | |||
will | will cause the hash to match this MP path. | |||
cause the hash to match this MP path. | ||||
type 2 - a list of single IP addresses is provided, any one of | type 2 - a list of single IP addresses is provided, any one of | |||
which will cause the hash to match this MP path. | which will cause the hash to match this MP path. | |||
type 3 - a list of label ranges is provided, any one of which will | type 3 - a list of label ranges is provided, any one of which will | |||
cause the hash to match this MP path. | cause the hash to match this MP path. | |||
type 4 - a list of IP address ranges is provided, any one of which | type 4 - a list of IP address ranges is provided, any one of which | |||
will cause the hash to match this MP path. | will cause the hash to match this MP path. | |||
type 5 - if no more labels are provided on the stack, this MP path | type 5 - if no more labels are provided on the stack, this MP path | |||
will apply (can only appear once). | will apply (can only appear once). | |||
type 6 - Any IP addresses matches. Undertlying labels may go | type 6 - Any IP addresses matches. Underlying labels may go | |||
elsewhere, but all IP takes only one MP path (can only | elsewhere, but all IP takes only one MP path (can only | |||
appear once). | appear once). | |||
type 7 - no matches are possible given the set of "Multipath | type 7 - no matches are possible given the set of "Multipath | |||
Exercise TLV" provided by prior hops. | Exercise TLV" provided by prior hops. | |||
If prior hops provide a "Downstream Multipath Mapping TLV" the labels | If prior hops provide a "Downstream Multipath Mapping TLV" the labels | |||
and IP addresses should be picked from the set provided in prior | and IP addresses should be picked from the set provided in prior | |||
"Multipath Exercise TLV" or "Hash Key Type" of 7 used. | "Multipath Exercise TLV" or "Hash Key Type" of 7 used. | |||
For example, suppose LSR X at hop 10 has two downstream LSRs Y and Z | ||||
for the FEC in question. X could return Hash Key Type 4, with | ||||
low/high IP addresses of 1.1.1.1->1.1.1.255 for downstream LSR Y and | ||||
2.1.1.1->2.1.1.255 for downstream LSR Z. The head end reflects this | ||||
information to LSR Y. Y, which has three downstream LSRs U, V and W, | ||||
computes that 1.1.1.1->1.1.1.127 would go to U and 1.1.1.128-> | ||||
1.1.1.255 would go to V. Y would then respond with 3 Downstream | ||||
Mappings: to U, with Hash Key Type 4 (1.1.1.1->1.1.1.127); to V, with | ||||
Hash Key Type 4 (1.1.1.127->1.1.1.255); and to W, with Hash Key Type | ||||
7. | ||||
3.3. Pad TLV | 3.3. Pad TLV | |||
The value part of the Pad TLV contains a variable number (>= 1) of | The value part of the Pad TLV contains a variable number (>= 1) of | |||
octets. The first octet takes values from the following table; all | octets. The first octet takes values from the following table; all | |||
the other octets (if any) are ignored. The receiver SHOULD verify | the other octets (if any) are ignored. The receiver SHOULD verify | |||
that the TLV is received in its entirety, but otherwise ignores the | that the TLV is received in its entirety, but otherwise ignores the | |||
contents of this TLV, apart from the first octet. | contents of this TLV, apart from the first octet. | |||
Value Meaning | Value Meaning | |||
----- ------- | ----- ------- | |||
1 Drop Pad TLV from reply | 1 Drop Pad TLV from reply | |||
2 Copy Pad TLV to reply | 2 Copy Pad TLV to reply | |||
3-255 Reserved for future use | 3-255 Reserved for future use | |||
3.4. Error Code | 3.4. Error Code | |||
The Error Code TLV is currently not defined; its purpose is to | The Error Code TLV is currently not defined; its purpose is to | |||
provide a mechanism for a more elaborate error reporting structure, | provide a mechanism for a more elaborate error reporting structure, | |||
should the reason arise. | should the reason arise. | |||
3.5. Vendor Enterprise Code | ||||
The Length is always 4; the value is the SMI Enterprise code, in | ||||
network octet order, of the vendor with a Vendor Private extension to | ||||
any of the fields in the fixed part of the message, in which case | ||||
this TLV MUST be present. If none of the fields in the fixed part of | ||||
the message have vendor private extensions, this TLV is OPTIONAL. | ||||
4. Theory of Operation | 4. Theory of Operation | |||
An MPLS echo request is used to test a particular LSP. The LSP to be | An MPLS echo request is used to test a particular LSP. The LSP to be | |||
tested is identified by the "FEC Stack"; for example, if the LSP was | tested is identified by the "FEC Stack"; for example, if the LSP was | |||
set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC | set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC | |||
stack contains a single element, namely, an LDP IPv4 prefix sub-TLV | stack contains a single element, namely, an LDP IPv4 prefix sub-TLV | |||
with value 10.1.1.1/32. If the LSP being tested is an RSVP LSP, the | with value 10.1.1.1/32. If the LSP being tested is an RSVP LSP, the | |||
FEC stack consists of a single element that captures the RSVP Session | FEC stack consists of a single element that captures the RSVP Session | |||
and Sender Template which uniquely identifies the LSP. | and Sender Template which uniquely identifies the LSP. | |||
skipping to change at page 15, line 30 | skipping to change at page 16, line 5 | |||
possible paths. However, full coverage may not be possible. | possible paths. However, full coverage may not be possible. | |||
4.2. Sending an MPLS Echo Request | 4.2. Sending an MPLS Echo Request | |||
An MPLS echo request is a (possibly) labelled UDP packet. The IP | 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 | header is set as follows: the source IP address is a routable address | |||
of the sender; the destination IP address is a (randomly chosen) | 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 | 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 | chosen by the sender; the destination UDP port is set to 3503 | |||
(assigned by IANA for MPLS echo requests). The Router Alert option | (assigned by IANA for MPLS echo requests). The Router Alert option | |||
is set in the IP header. If the echo request is labelled, the MPLS | is set in the IP header. | |||
TTL on all the labels except the outermost should be set to 1. | ||||
If the echo request is labelled, one may (depending on what is being | ||||
pinged) set the TTL of the innermost label to 1, to prevent the ping | ||||
request going farther than it should. Examples of this include | ||||
pinging a VPN IPv4 or IPv6 prefix, an L2 VPN end point or an L2 | ||||
circuit ID. This can also be accomplished by inserting a router | ||||
alert label above this label; however, this may lead to the undesired | ||||
side effect that MPLS echo requests take a different data path than | ||||
actual data. | ||||
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. In "traceroute" mode (fault isolation | outermost label is set to 255. In "traceroute" mode (fault isolation | |||
mode), the TTL is set successively to 1, 2, .... | mode), the TTL is set successively to 1, 2, .... | |||
The sender chooses a Sender's Handle, and a Sequence Number. When | The sender chooses a Sender's Handle, and a Sequence Number. When | |||
sending subsequent MPLS echo requests, the sender SHOULD increment | sending subsequent MPLS echo requests, the sender SHOULD increment | |||
the sequence number by 1. However, a sender MAY choose to send a | the sequence number by 1. However, a sender MAY choose to send a | |||
group of echo requests with the same sequence number to improve the | group of echo requests with the same sequence number to improve the | |||
chance of arrival of at least one packet with that sequence number. | chance of arrival of at least one packet with that sequence number. | |||
skipping to change at page 16, line 25 | skipping to change at page 17, line 9 | |||
An LSR X that receives an MPLS echo request first parses the packet | An LSR X that receives an MPLS echo request first parses the packet | |||
to ensure that it is a well-formed packet, and that the TLVs are | to ensure that it is a well-formed packet, and that the TLVs are | |||
understood. If not, X SHOULD send an MPLS echo reply with the Return | understood. If not, X SHOULD send an MPLS echo reply with the Return | |||
Code set to "Malformed echo request received" or "TLV not understood" | Code set to "Malformed echo request received" or "TLV not understood" | |||
(as appropriate), and the Subcode set to the appropriate value. | (as appropriate), and the Subcode set to the appropriate value. | |||
If the echo request is good, X then checks whether it is a valid | If the echo request is good, X then checks whether it is a valid | |||
transit or egress LSR for the FEC in the echo request. If not, X MAY | transit or egress LSR for the FEC in the echo request. If not, X MAY | |||
log this fact. If it is, X notes that interface I over which the | log this fact. If it is, X notes that interface I over which the | |||
echo was received, and the label L with which it came. X checks | echo was received, and the label L with which it came. X checks | |||
whether it actually advertised L over interface I for the FEC in the | whether it actually advertised L for the FEC in the echo request; X | |||
echo request. | MAY further check whether it expects L over interface I or not. | |||
If the echo request contains a Downstream Mapping TLV, X MUST further | If the echo request contains a Downstream Mapping TLV, X MUST further | |||
check whether its Router ID matches one of the Downstream IPv4 Router | check whether its Router ID or one of its interface addresses matches | |||
IDs; and if so, whether the given Downstream Label is in fact the | one of the Downstream IPv4 Address; if the Address Type is | |||
label that X sent as its mapping for the FEC over the downstream | Unnumbered, X further checks if the interface I has the given | |||
interface. The result of the checks in the previous and this | (upstream) index. If these check out, X determines whether the given | |||
paragraph are captured in the Return Code/Subcode. | Downstream Label is in fact the label that X sent as its mapping for | |||
the FEC over the downstream interface. 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, X uses the | If the echo request has a Reply Mode that wants a reply, X uses the | |||
procedure in the next subsection to send the echo reply. | procedure in the next subsection to send the echo reply. | |||
4.4. Sending an MPLS Echo Reply | 4.4. Sending an MPLS Echo Reply | |||
An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response | An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response | |||
to an MPLS echo request. The source IP address is a routable address | to an MPLS echo request. The source IP address is a routable address | |||
of the replier; the source port is the well-known UDP port for 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 | |||
skipping to change at page 18, line 5 | skipping to change at page 18, line 39 | |||
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 | |||
Mapping. | Mapping. | |||
5. Reliable Reply Path | Normative References | |||
One of the issues that are faced with MPLS ping is to distinguish | ||||
between a failure in the forward path (the MPLS path being 'pinged') | ||||
and a failure in the return path. Note that this problem exists with | ||||
vanilla IP ping as well. In the case of MPLS ping, it is assumed | ||||
that the IP control and data planes are reliable. However, it could | ||||
be that the forwarding in the return path is via an MPLS LSP. | ||||
In this specification, we give two solutions for this problem. One | ||||
is to set the Router Alert option in the MPLS echo reply. When a | ||||
router sees this option, it MUST forward the packet as an IP packet. | ||||
Note that this may not work if some transit LSR does not support MPLS | ||||
ping. | ||||
Another option is to send the echo reply via the control plane. At | ||||
present, this is defined only for RSVP-TE LSPs, and described below. | ||||
These options are controlled by the ingress LSR, using the Reply Mode | ||||
in the MPLS echo request packet. | ||||
5.1. RSVP-TE Extension | ||||
To test an LSP's liveliness, an ingress LSR sends MPLS echo requests | ||||
over the LSP being tested. When an egress LSR receives the message, | ||||
it needs to acknowledge the ingress LSR by sending an LSP_ECHO object | ||||
in a RSVP Resv message. The object has the following format: | ||||
Class = LSP_ECHO (use form 11bbbbbb for compatibility) | ||||
C-Type = 1 | ||||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sequence Number | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| TimeStamp (seconds) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| TimeStamp (microseconds) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| UDP Source Port | Return Code | Return Subcode| | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
The Sequence Number is copied from the Sequence Number of the echo | ||||
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 | ||||
the MPLS echo request. The FEC is implied by the Session and the | ||||
Sender Template Objects. | ||||
5.2. Operation | ||||
For the sake of brevity in the context of this document by "the | ||||
control plane" we mean "the RSVP-TE component of the control plane". | ||||
Consider an LSP between an ingress LSR and an egress LSR spanning | ||||
multiple LSR hops. | ||||
5.3. Procedures at the ingress LSR | ||||
One must ensure before setting the Reply Mode to "reply via the | ||||
control plane" that the egress LSR supports this feature. | ||||
The ingress LSR, say X, builds an MPLS echo request as in section | ||||
"Sending an MPLS Echo Request". The FEC Type must be an RVSP Session | ||||
Query. X also sets the Reply Mode to "reply via the control plane". | ||||
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 | ||||
the LSP as "down". At this point, the ingress LSR may apply the | ||||
necessary procedures to fix the LSP. These may include generating a | ||||
message to network management, tearing-down and re-building the LSP, | ||||
and/or rerouting user traffic to a backup LSP. | ||||
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 | ||||
be prepended to such messages. The ingress and egress LSR's must | ||||
follow the procedures defined in [LABEL-STACK]. | ||||
5.4. Procedures at the egress LSR | ||||
When the egress LSR receives an MPLS ping message, it follows the | ||||
procedures given above. If the Reply Mode is set to "Reply via the | ||||
control plane", the LSR can, based on the RSVP SESSION and | ||||
SENDER_TEMPLATE objects carried in the MPLS ping message, find the | ||||
corresponding LSP in its RSVP-TE database. The LSR then checks to | ||||
see if the Resv message for this LSP contains an LSP_ECHO object with | ||||
the same source UDP port value. If not, the LSR adds or updates the | ||||
LSP_ECHO object and refreshes the Resv message. | ||||
5.5. Procedures for the intermediate LSR's | ||||
At intermediate LSRs, normal RSVP processing procedures will cause | ||||
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 | ||||
LSP_ECHO object MUST be delivered upstream immediately. | ||||
Note that an intermediate LSR using RSVP refresh reduction [RSVP- | ||||
REFRESH], the new or changed LSP_ECHO object will cause the LSR to | ||||
classify the RSVP message as a trigger message. | ||||
6. Normative References | ||||
[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", RFC | [LABEL-STACK] Rosen, E., et al, "MPLS Label Stack Encoding", RFC | |||
3032, January 2001. | 3032, January 2001. | |||
[RSVP] Braden, R. (Editor), et al, "Resource ReSerVation protocol | [RSVP] Braden, R. (Editor), et al, "Resource ReSerVation protocol | |||
(RSVP) -- Version 1 Functional Specification," RFC 2205, | (RSVP) -- Version 1 Functional Specification," RFC 2205, | |||
September 1997. | September 1997. | |||
[RSVP-REFRESH] Berger, L., et al, "RSVP Refresh Overhead Reduction | [RSVP-REFRESH] Berger, L., et al, "RSVP Refresh Overhead Reduction | |||
Extensions", RFC 2961, April 2001. | Extensions", RFC 2961, April 2001. | |||
[RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP | [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP | |||
tunnels", RFC 3209, December 2001. | tunnels", RFC 3209, December 2001. | |||
7. Informative References | Informative References | |||
[ICMP] Postel, J., "Internet Control Message Protocol", RFC 792. | [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792. | |||
[LDP] Andersson, L., et al, "LDP Specification", RFC 3036, January | [LDP] Andersson, L., et al, "LDP Specification", RFC 3036, January | |||
2001. | 2001. | |||
8. Security Considerations | Security Considerations | |||
There are at least two approaches to attacking LSRs using the | There are at least two approaches to attacking LSRs using the | |||
mechanisms defined here. One is a Denial of Service attack, by | mechanisms defined here. One is a Denial of Service attack, by | |||
sending MPLS echo requests/replies to LSRs and thereby increasing | sending MPLS echo requests/replies to LSRs and thereby increasing | |||
their workload. The other is obfuscating the state of the MPLS data | their workload. The other is obfuscating the state of the MPLS data | |||
plane liveness by spoofing, hijacking, replaying or otherwise | plane liveness by spoofing, hijacking, replaying or otherwise | |||
tampering with MPLS echo requests and replies. | tampering with MPLS echo requests and replies. | |||
Authentication will help reduce the number of seemingly valid MPLS | Authentication will help reduce the number of seemingly valid MPLS | |||
echo requests, and thus cut down the Denial of Service attacks; | echo requests, and thus cut down the Denial of Service attacks; | |||
skipping to change at page 21, line 14 | skipping to change at page 20, line 5 | |||
tampering attacks; one hopes to use some mechanism devised or | tampering attacks; one hopes to use some mechanism devised or | |||
suggested by the RPSec WG. It is not clear how to prevent hijacking | suggested by the RPSec WG. It is not clear how to prevent hijacking | |||
(non-delivery) of echo requests or replies; however, if these | (non-delivery) of echo requests or replies; however, if these | |||
messages are indeed hijacked, MPLS ping will report that the data | messages are indeed hijacked, MPLS ping will report that the data | |||
plane isn't working as it should. | plane isn't working as it should. | |||
It doesn't seem vital (at this point) to secure the data carried in | It doesn't seem vital (at this point) to secure the data carried in | |||
MPLS echo requests and replies, although knowledge of the state of | MPLS echo requests and replies, although knowledge of the state of | |||
the MPLS data plane may be considered confidential by some. | the MPLS data plane may be considered confidential by some. | |||
9. IANA Considerations | 5. IANA Considerations | |||
(To be filled in a later revision) | The TCP and UDP port number 3503 has been allocated by IANA for LSP | |||
echo requests and replies. | ||||
10. Acknowledgments | The following sections detail the new name spaces to be managed by | |||
IANA. For each of these name spaces, the space is divided into | ||||
assignment ranges; the following terms are used in describing the | ||||
procedures by which IANA allocates values: "Standards Action" (as | ||||
defined in [IANA]); "Expert Review" and "Vendor Private Use". | ||||
Values from "Expert Review" ranges MUST be registered with IANA, and | ||||
MUST be accompanied by an Experimental RFC that describes the format | ||||
and procedures for using the code point. | ||||
Values from "Vendor Private" ranges MUST NOT be registered with IANA; | ||||
however, the message MUST contain an enterprise code as registered | ||||
with the IANA SMI Network Management Private Enterprise Codes. For | ||||
each name space that has a Vendor Private range, it must be specified | ||||
where exactly the SMI Enterprise Code resides; see below for | ||||
examples. In this way, several enterprises (vendors) can use the | ||||
same code point without fear of collision. | ||||
5.1. Message Types, Reply Modes, Return Codes | ||||
It is requested that IANA maintain registries for Message Types, | ||||
Reply Modes, Return Codes and Return Subcodes. Each of these can | ||||
take values in the range 0-255. Assignments in the range 0-191 are | ||||
via Standards Action; assignments in the range 192-251 are made via | ||||
Expert Review; values in the range 252-255 are for Vendor Private | ||||
Use, and MUST NOT be allocated. | ||||
If any of these fields fall in the Vendor Private range, a top-level | ||||
Vendor Enterprise Code TLV MUST be present in the message. | ||||
5.2. TLVs | ||||
It is requested that IANA maintain registries for the Type field of | ||||
top-level TLVs as well as for sub-TLVs. The valid range for each of | ||||
these is 0-65535. Assignments in the range 0-32767 are made via | ||||
Standards Action; assignments in the range 32768-64511 are made via | ||||
Expert Review; values in the range 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 | ||||
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. | ||||
The rest of the Value field is private to the vendor. | ||||
Acknowledgments | ||||
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 and Ina Minei. | Gan, Brook Bailey, Eric Rosen and Ina Minei. | |||
The Multipath Exercise sub-field of the Downstream Mapping TLV was | The Multipath Exercise sub-field of the Downstream Mapping TLV was | |||
adapted from text suggested by Curtis Villamizar. | adapted from text suggested by Curtis Villamizar. | |||
11. Appendix | Appendix | |||
This appendix specifies non-normative aspects of detecting MPLS data | This appendix specifies non-normative aspects of detecting MPLS data | |||
plane liveness. | plane liveness. | |||
11.1. CR-LDP FEC | 5.1. CR-LDP FEC | |||
This section describes how a CR-LDP FEC can be included in an Echo | This section describes how a CR-LDP FEC can be included in an Echo | |||
Request using the following FEC subtype: | Request using the following FEC subtype: | |||
Sub-Type # Length Value Field | Sub-Type # Length Value Field | |||
---------- ------ ----------- | ---------- ------ ----------- | |||
5 6 CR-LDP LSP ID | 5 6 CR-LDP LSP ID | |||
The value consists of the LSPID of the LSP being pinged. An LSPID is | 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 | a four octet IPv4 address (a local address on the ingress LSR, for | |||
skipping to change at page 22, line 9 | skipping to change at page 21, line 41 | |||
per LSP on a given ingress LSR. | per LSP on a given ingress LSR. | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Ingress LSR Router ID | | | Ingress LSR Router ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Must Be Zero | LSP ID | | | Must Be Zero | LSP ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
11.2. Downstream Mapping for CR-LDP | 5.2. Downstream Mapping for CR-LDP | |||
If a label in a Downstream Mapping was learned via CR-LDP, the | 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 field in the Mapping TLV can use the following entry: | |||
Protocol # Signaling Protocol | Protocol # Signaling Protocol | |||
---------- ------------------ | ---------- ------------------ | |||
5 CR-LDP | 5 CR-LDP | |||
12. Authors' Addresses | Authors' Addresses | |||
Kireeti Kompella | Kireeti Kompella | |||
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: nsheth@juniper.net | e-mail: nsheth@juniper.net | |||
Ping Pan | Ping Pan | |||
skipping to change at page 23, line 16 | skipping to change at page 23, line 5 | |||
email: swadhwa@unispherenetworks.com | email: swadhwa@unispherenetworks.com | |||
phone: +1 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: +1 703.886.1681 | phone: +1 703.886.1681 | |||
13. Intellectual Property Rights Notices | Intellectual Property Rights Notices | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
intellectual property or other rights that might be claimed to | intellectual property or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; neither does it represent that it | might or might not be available; neither does it represent that it | |||
has made any effort to identify any such rights. Information on the | has made any effort to identify any such rights. Information on the | |||
IETF's procedures with respect to rights in standards-track and | IETF's procedures with respect to rights in standards-track and | |||
standards-related documentation can be found in BCP-11. Copies of | standards-related documentation can be found in BCP-11. Copies of | |||
claims of rights made available for publication and any assurances of | claims of rights made available for publication and any assurances of | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |