--- 1/draft-smack-mpls-rfc4379bis-01.txt 2015-10-09 11:16:06.274743640 -0700 +++ 2/draft-smack-mpls-rfc4379bis-02.txt 2015-10-09 11:16:06.378746166 -0700 @@ -2,21 +2,21 @@ Network Working Group C. Pignataro Internet-Draft N. Kumar Obsoletes: 4379 (if approved) Cisco Intended status: Standards Track S. Aldrin Expires: March 29, 2016 Google M. Chen Huawei September 26, 2015 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures - draft-smack-mpls-rfc4379bis-01.txt + draft-smack-mpls-rfc4379bis-02 Abstract 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. @@ -83,33 +83,33 @@ 3.2.14. Generic IPv6 Prefix . . . . . . . . . . . . . . . . 21 3.2.15. Nil FEC . . . . . . . . . . . . . . . . . . . . . . 22 3.3. Downstream Mapping . . . . . . . . . . . . . . . . . . . 22 3.3.1. Multipath Information Encoding . . . . . . . . . . . 26 3.3.2. Downstream Router and Interface . . . . . . . . . . 28 3.4. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . 29 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. Theory of Operation . . . . . . . . . . . . . . . . . . . . 31 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 + 4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . 42 5. Security Considerations . . . . . . . . . . . . . . . . . . 43 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 - 6.1. Message Types, Reply Modes, Return Codes . . . . . . . . 45 + 6.1. Message Types, Reply Modes, Return Codes . . . . . . . . 44 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.1. Normative References . . . . . . . . . . . . . . . . . . 47 8.2. Informative References . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction This document describes a simple and efficient mechanism that can be @@ -182,28 +182,33 @@ 1.4. Scope of RFC4379bis work The goal of this document is to take LSP Ping to an Internet Standard. [RFC4379] defines the basic mechanism for MPLS LSP validation that can be used for fault detection and isolation. The scope of this document also is to address various updates to MPLS LSP Ping, including: - 1. Updates to all references and citations. + 1. Updates to all references and citations. Obsoleted RFCs 2434, + 2030, and 3036 are respectively replaced with RFCs 5226, 5905, + and 5036. Additionally, these three documents published as RFCs: + RFCs 4447, 5085, and 4761. + 2. Incorporate all outstanding Errata. These include Errata with + IDs: 108, 1418, 1714, 1786, 3399, 742, and 2978. 1.5. ToDo Please remove this ToDo prior to publication: - 1. Incorporate Errata - 2. Review IANA Allocations + 1. Review IANA Allocations + 2. Fix pending figure mis-alignments 2. Motivation 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 tool that would enable users to detect such traffic "black holes" or misrouting within a reasonable period of time, and a mechanism to isolate faults. In this document, we describe a mechanism that accomplishes these @@ -321,25 +326,25 @@ | Version Number | Global Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Reply mode | Return Code | Return Subcode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Sent (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TimeStamp Sent (microseconds) | + | TimeStamp Sent (seconds fraction) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Received (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TimeStamp Received (microseconds) | + | TimeStamp Received (seconds fraction) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs ... | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Version Number is currently 1. (Note: the version number is to be incremented whenever a change is made that affects the ability of @@ -405,25 +410,25 @@ 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) in NTP format [RFC5905] 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. + The TimeStamp Sent is the time-of-day (according to the sender's + clock) in NTP format [RFC5905] 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 | . . @@ -451,21 +456,21 @@ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length for this TLV is 5. A Target FEC Stack TLV that contains an LDP IPv4 FEC sub-TLV and a VPN IPv4 prefix sub-TLV has 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 = 1 (FEC TLV) | Length = 12 | + | Type = 1 (FEC TLV) | Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-Type = 1 (LDP IPv4 FEC) | Length = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-Type = 6 (VPN IPv4 prefix)| Length = 13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | @@ -1156,21 +1161,21 @@ 2 BGP 3 LDP 4 RSVP-TE 3.3.1. Multipath Information Encoding The Multipath Information encodes labels or addresses that will exercise this path. The Multipath Information depends on the Multipath Type. The contents of the field are shown in the table above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses - are drawn from the range 0:0:0:0:0:FFFF:127/104. Labels are treated + are drawn from the range 0:0:0:0:0:FFFF:7F00/104. Labels are treated as numbers, i.e., they are right justified in the field. For Type 4, ranges indicated by Address pairs MUST NOT overlap and MUST be in ascending sequence. Type 8 allows a more dense encoding of IP addresses. The IP prefix is formatted as a base IP address with the non-prefix low-order bits set to zero. The maximum prefix length is 27. Following the prefix is a mask of length 2^(32-prefix length) bits for IPv4 and 2^(128-prefix length) bits for IPv6. Each bit set to 1 represents a valid address. The address is the base IPv4 address plus the @@ -1189,22 +1194,20 @@ Those same addresses embedded in IPv6 would be encoded 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 9 allows a more dense encoding of labels. The label prefix is formatted as a base label value with the non-prefix low-order bits set to zero. The maximum prefix (including leading zeros due to @@ -1480,22 +1482,22 @@ 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 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) IPv4 address from the range 127/8 or IPv6 address from the range - 0:0:0:0:0:FFFF:127/104. The IP TTL is set to 1. The source UDP port - is chosen by the sender; the destination UDP port is set to 3503 + 0:0:0:0:0:FFFF:7F00/104. 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. 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 [RFC3209]. 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 sending the packet. @@ -1514,23 +1516,22 @@ In "ping" mode (end-to-end connectivity check), the TTL in the outermost label is set to 255. In "traceroute" mode (fault isolation mode), the TTL is set successively to 1, 2, and so on. 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. - The TimeStamp Sent is set to the time-of-day (in seconds and - microseconds) that the echo request is sent. The TimeStamp Received - is set to zero. + The TimeStamp Sent is set to the time-of-day in NTP format that the + echo request is sent. The TimeStamp Received is set to zero. An MPLS echo request MUST have an 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 Sending an MPLS echo request to the control plane is triggered by one of the following packet processing exceptions: Router Alert option, @@ -1577,21 +1578,21 @@ Label-stack-depth: the depth of label being verified. Initialized to the number of labels in the received label stack S. 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. Best-return-code: contains the return code for the echo reply - packet as currently best known. As algorithm + packet as currently best known. As the algorithm progresses, this code may change depending on the results of further checks that it performs. Best-rtn-subcode: similar to Best-return-code, but for the Echo Reply Subcode. FEC-status: result value returned by the FEC Checking algorithm described in section 4.4.1. /* Save receive context information */ @@ -1636,25 +1636,26 @@ 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 check). + NHLFE and proceed to step 4 (Label Operation check). } 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 @@ -1724,33 +1726,34 @@ /* 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. + above stack-depths, the bottom is considered to be entry 1. */ Set FEC-stack-depth to 0. Set i to Label-stack-depth. 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 number of FECs in the FEC stack is greater than or equal + to FEC-stack-depth { Perform the FEC Checking procedure (see subsection 4.4.1 below). If FEC-status is 2, set Best-return-code to 10 ("Mapping for this FEC is not the given label at stack-depth"). If the return code is 1, set Best-return-code to FEC-return- code and Best-rtn-subcode to FEC-stack-depth. } @@ -1800,21 +1804,21 @@ 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. + echo reply are found in subsection 4.5. 4.4.1. FEC Validation /* This subsection describes validation of an FEC entry within the Target FEC Stack and accepts an 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. @@ -1965,21 +1969,21 @@ to the control plane. A rate limiter SHOULD be applied to the well- known UDP port defined below. 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 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 defense, an implementation MAY also validate the TimeStamp - Sent by requiring and exact match on this field. + Sent by requiring an exact match on this field. To protect against unauthorized sources using MPLS echo request messages to obtain network information, it is RECOMMENDED that implementations provide 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 is not working as it should.