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