--- 1/draft-ietf-mpls-proxy-lsp-ping-04.txt 2015-03-25 14:15:15.746583150 -0700 +++ 2/draft-ietf-mpls-proxy-lsp-ping-05.txt 2015-03-25 14:15:15.802584512 -0700 @@ -1,20 +1,20 @@ Network Working Group G. Swallow Internet-Draft V. Lim Intended status: Standards Track Cisco Systems -Expires: August 30, 2015 S. Aldrin +Expires: September 26, 2015 S. Aldrin Huawei Technologies - February 26, 2015 + March 25, 2015 Proxy MPLS Echo Request - draft-ietf-mpls-proxy-lsp-ping-04 + draft-ietf-mpls-proxy-lsp-ping-05 Abstract This document defines a means of remotely initiating Multiprotocol Label Switched Protocol Pings on Label Switched Paths. An MPLS Proxy Ping Request is sent to any Label Switching Router along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to leaf/root tracing. @@ -33,21 +33,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on August 30, 2015. + This Internet-Draft will expire on September 26, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -70,53 +70,61 @@ 3.1. Procedures for the initiator . . . . . . . . . . . . . . . 7 3.2. Procedures for the Proxy LSR . . . . . . . . . . . . . . . 8 3.2.1. Proxy LSR Handling when it is egress for FEC . . . . . 10 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply . . 11 3.2.3. Sending an MPLS Proxy Ping Reply . . . . . . . . . . . 12 3.2.4. Sending the MPLS Echo Requests . . . . . . . . . . . . 12 3.2.4.1. Forming the base MPLS Echo Request . . . . . . . . 12 3.2.4.2. Per interface sending procedures . . . . . . . . . 14 4. Proxy Ping Request / Reply Messages . . . . . . . . . . . . . 14 4.1. Proxy Ping Request / Reply Message formats . . . . . . . . 14 - 4.2. Proxy Ping Request Message contents . . . . . . . . . . . 14 + 4.2. Proxy Ping Request Message contents . . . . . . . . . . . 15 4.3. Proxy Ping Reply Message Contents . . . . . . . . . . . . 15 - 5. TLV formats . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 5.1. Proxy Echo Parameters TLV . . . . . . . . . . . . . . . . 15 + 5. TLV formats . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1. Proxy Echo Parameters TLV . . . . . . . . . . . . . . . . 16 5.1.1. Next Hop sub-TLV . . . . . . . . . . . . . . . . . . . 19 5.2. Reply-to Address TLV . . . . . . . . . . . . . . . . . . . 20 5.3. Upstream Neighbor Address TLV . . . . . . . . . . . . . . 20 5.4. Downstream Neighbor Address TLV . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8.1. Proxy Echo Parameters Sub-TLVs . . . . . . . . . . . . . . 23 - + 8.2. Downstream Address Mapping Registry [pending IANA + assignment] . . . . . . . . . . . . . . . . . . . . . . . 24 + 8.3. Next Hop Sub-TLV Address Type Registry . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction This document is motivated by two broad issues in connection with diagnosing Point-to-Multipoint (P2MP) Label Switched Paths (LSPs). The first is scalability due to the automatic replication of Multiprotocol Label Switching (MPLS) Echo Request Messages as they proceed down the tree. The second, which is primarily motivated by Label Distribution Protocol based Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths [RFC6388], is the ability to trace a sub-LSP from leaf node to root node. - It is anticipated that very large Point-to-Multipoint and Multipoint- - to-Multipoint (MP2MP) Label Switched Paths will exist. Further it is - anticipated that many of the applications for P2MP/MP2MP tunnels will - require OAM that is both rigorous and scalable. + When tracing from a source to a particular leaf in a P2MP or MP2MP + tree, nodes not along that path will need to process MPLS Echo + Request messages that are received. The number of MPLS Echo Replies + sent in response to an MPLS Echo Request quickly multiplies, as the + Label Switching Routers (LSRs), which are part of the tree but not + along the path of the trace could be responding to the received MPLS + Echo Request as well. This could also overwhelm the source to process + all the MPLS Echo Reply messages it receives. It is anticipated that + many of the applications for P2MP/MP2MP tunnels will require OAM that + is both rigorous and scalable. Suppose one wishes to trace a P2MP LSP to localize a fault which is affecting one egress or a set of egresses. Suppose one follows the normal procedure for tracing - namely repeatedly pinging from the root, incrementing the Time to Live (TTL) by one after each three or so pings. Such a procedure has the potential for producing a large amount of processing at the P2MP-LSP midpoints and egresses. It also could produce an unwieldy number of replies back to the root. One alternative would be to begin sending pings from points at or @@ -185,77 +193,75 @@ Based on context the terms leaf and egress are used interchangeably. Egress is used where consistency with[RFC4379] was deemed appropriate. Receiver is used in the context of receiving protocol messages. 1.2. Terminology Term Definition ----- ------------------------------------------- - LSP Label Switched Paths + LSP Label Switched Path LSR Label Switching Router mLDP Multipoint LDP MP2MP Multipoint to Multipoint MTU Maximum Transmission Unit P2MP Point to Multipoint TTL Time to Live - [Note (to be removed after assignments occur): = to be assigned - by IANA] - 2. Proxy Ping Overview - This document defines a protocol interaction between a first node, a - node which is part of an LSP, to allow the first node to request that - the second node initiate an LSP ping for the LSP on the first node's - behalf. Since the second node sends the LSP Ping on behalf of the - first node, it does not maintain state to be able to handle the + This document defines a protocol interaction between a first LSR, an + LSR which is part of an LSP, to allow the first LSR to request that + the second LSR initiate an LSP ping for the LSP on the first LSR's + behalf. Since the second LSR sends the LSP Ping on behalf of the + first LSR, it does not maintain state to be able to handle the corresponding LSP Ping response. Instead the responder to the LSP - ping sends the LSP Ping response to either the first node or another - node configured to handle it. Two new LSP Ping messages are defined + ping sends the LSP Ping response to either the first LSR or another + LSR configured to handle it. Two new LSP Ping messages are defined for remote pinging: the MPLS Proxy Ping Request and the MPLS Proxy Ping Reply. A remote ping operation on a P2MP LSP generally involves at least three LSRs; in some scenarios none of these are the ingress (root) or an egress (leaf) of the LSP. - We refer to these nodes with the following terms: + We refer to these LSRs with the following terms: - Initiator - the node which initiates the ping operation by sending + Initiator - the LSR which initiates the ping operation by sending an MPLS Proxy Ping Request message - Proxy LSR - the node which is the destination of the MPLS Proxy + Proxy LSR - the LSR which is the destination of the MPLS Proxy Ping Request message and potential initiator of the MPLS Echo Request - Receiver(s) - the nodes which receive the MPLS Echo Request + Receiver(s) - the LSR(s) which receive the MPLS Echo Request message + Responder - A receiver that responds to an MPLS Proxy Ping Request or an MPLS Echo Request We note that in some scenarios, the initiator could also be the - responder, in which case the response would be internal to the node. + responder, in which case the response would be internal to the LSR. 2.1. Initiating Proxy Ping The initiator formats an MPLS Proxy Ping Request message and sends it - to the Proxy LSR, a node it believes to be on the path of the LSP. + to the Proxy LSR, an LSR it believes to be on the path of the LSP. This message instructs the Proxy LSR to either Reply with Proxy information or to send an MPLS Echo Request inband of the LSP. The initiator requests Proxy information so that it can learn additional information it needs to use to form a subsequent MPLS Proxy Ping Request. For example, during LSP traceroute an initiator needs the downstream map information to form an MPLS Echo Request. An initiator may also want to learn a Proxy LSR's FEC neighbor information so that - it can form Proxy Ping Requests to various nodes along the LSP. + it can form Proxy Ping Requests to various LSRs along the LSP. 2.2. Handling at Proxy LSR The Proxy LSR either replies with the requested Proxy information or it validates that it has a label mapping for the specified FEC and that it is authorized to send the specified MPLS Echo Request on behalf of the initiator. If the Proxy LSR has a label mapping for the FEC and all authorization checks have passed, the Proxy LSR formats an MPLS Echo @@ -292,30 +297,32 @@ The initiator creates an MPLS Proxy Ping request message. The message MUST contain a Target FEC Stack that describes the FEC being tested. The topmost FEC in the target FEC stack is used at the Proxy LSR to lookup the MPLS label stack that will be used to encapsulate the MPLS Echo Request packet. The MPLS Proxy Ping Request message MUST contain a Proxy Echo Parameters TLV. In that TLV, the address type is set to either IPv4 - or IPv6. The Destination IP Address is set to the value to be used in - the MPLS Echo Request packet. If the Address Type is IPv4, an address - is from the range 127/8. If the Address Type is IPv6, an address is - from the range ::FFFF:7F00:0/104. + or IPv6. The Destination IP Address is set to the value to be used by + the Proxy LSR to build the MPLS Echo Request packet. The MPLS Echo + Request IP header destination address as specified in [RFC4379], if + the Address Type is IPv4, MUST be an address is from the range 127/8; + If the Address Type is IPv6, MUST be an address from the range + ::FFFF:7F00:0/104. The Reply mode and Global Flags of the Proxy Echo Parameters TLV are set to the values to be used in the MPLS Echo Request message header. The Source UDP Port is set to the value to be used in the MPLS Echo Request (the source port is supplied by the Proxy Ping initiator - because it or a node known to it handles the LSP ping responses). The + because it or an LSR known to it handles the LSP ping responses). The TTL is set to the value to be used in the outgoing MPLS label stack. See Section 5.1 for further details. If the FEC's Upstream/Downstream Neighbor address information is required, the initiator sets the "Request for FEC neighbor information" Proxy Flags in the Proxy Echo Parameters TLV. If a Downstream Detailed or Downstream Mapping TLV is required in an MPLS Proxy Ping Reply, the initiator sets the "Request for Downstream Detailed Mapping" or "Request for Downstream Mapping" Proxy Flags in @@ -379,26 +385,33 @@ Subcode is set to zero for both cases. If the Reply Mode of the message header is not 1(Do not reply), an MPLS Proxy Ping Reply message SHOULD be sent as described below. If the Return Code is "TLV not understood", no more processing of the MPLS Proxy Ping Request message is required. The Proxy LSR sends an MPLS Proxy Ping Reply message with an Errored TLVs TLV containing all the not understood TLVs (only). - The Proxy LSR checks that the MPLS Proxy Ping Request message did not - arrive via one of its exception processing paths. Packets arriving - via IP TTL expiry, IP destination address set to a Martian address or - label ttl expiry MUST be treated as "Unauthorized" packets. An MPLS - Proxy Ping Reply message MAY be sent with a Return Code of , - "Proxy Ping not authorized". + The MPLS Proxy Ping Request is expected to be transported to the + Proxy LSR via IP forwarding mechanisms instead of using the same + techniques that are employed to inject an MPLS Echo Request packet + into an LSP and use IP TTL, MPLS TTL and or loopback addresses (IPv4 + 127.x.x.x/IPv6::FFF:127/104) in the IP header destination address + field to trigger the packet to be handled via an LSR's forwarding + exception processing path. To gaurd against this, the Proxy LSR + checks that the MPLS Proxy Ping Request message did not arrive via + one of its exception processing paths. Packets arriving via IP TTL + expiry, IP destination address set to a loopback address or label ttl + expiry MUST be treated as "Unauthorized" packets. An MPLS Proxy Ping + Reply message MAY be sent with a Return Code of , "Proxy Ping + not authorized". The header fields Sender's Handle and Sequence Number are not examined, but they are included in the MPLS Proxy Ping Reply or MPLS Echo Request message, if either is sent as a direct result of the received message. The Proxy LSR validates that it has a label mapping for the specified FEC, it then determines if it is an ingress, egress, transit or bud node and sets the Return Code as appropriate. A new Return Code of , "Replying router has FEC mapping for topmost FEC" has been @@ -437,83 +450,82 @@ removing unrecognized Next Hop sub-TLVs. The updated Proxy Echo Parameters TLV MUST be included in the MPLS Proxy Ping Reply. If the "Request for Downstream Detailed Mapping" or "Request for Downstream Mapping" flag is set, the Proxy LSR formats (for inclusion in the MPLS Proxy Ping Reply) a Downstream Detailed/Downstream Mapping (DD/DSMAP) TLV for each interface over which the MPLS Echo Request will be sent. If the Proxy LSR is the egress for the FEC, the behavior of the Proxy - LSR varies depending on whether the node is an egress of a P2P LSP, a + LSR varies depending on whether the LSR is an egress of a P2P LSP, a P2MP LSP or MP2MP LSP. Additional details can be found in the section describing "Handling when Proxy LSR it is egress for FEC". If the Reply Mode of the MPLS Proxy Ping Request message header is "1 - do not reply", no MPLS Proxy Ping Reply is sent. Otherwise an MPLS Proxy Ping Reply message or MPLS Echo Request SHOULD be sent as described below. 3.2.1. Proxy LSR Handling when it is egress for FEC This section describes the different behaviors for the Proxy LSR when it's the egress for the FEC. In the P2MP budnode and MP2MP budnode and egress cases, different behavior is required. - In the case where an LSP ping is originated from P2MP/MP2MP bud - node/egress, MPLS Echo Replies are returned from downstream/upstream - routers and won't include an MPLS Echo Reply from the node that - originated the MPLS Echo Requests. This section describes the - behavior required at the bud/egress node to return information not - returned by MPLS Echo Replies in the Proxy Echo Reply so that there - is no additional changes required in the [RFC4379] implementations. - The Proxy Initiator should receive the same MPLS Echo Replies as in - the case where of the originator of the LSP ping, any additional - information such as the Proxy LSR being a bud node/egress is returned - in the MPLS Proxy Ping Reply. + In the case where an MLSP Echo Request is originated by an LSR which + is a bud or egress node of a P2MP/MP2MP, MPLS Echo Replies are + returned from downstream/upstream LSRs and will not include an MPLS + Echo Reply from the LSR that originated the MPLS Echo Request. This + section describes the behavior required at a bud or egress node to + return or not return information from MPLS Echo Replies in the Proxy + Echo Reply so that no changes are required in [RFC4379] compliant + implementations. The Proxy Initiator should receive the same MPLS + Echo Replies as in the case where of the originator of the LSP ping, + any additional information such as the Proxy LSR being a bud or + egress node is returned in the MPLS Proxy Ping Reply. When the Proxy LSR is the egress of a P2P FEC, an MPLS Proxy Ping Reply SHOULD be sent to the initiator with the Return Code set to 3, "Reply router is egress for FEC", with Return Subcode set to 0. When the Proxy LSR is the egress of a P2MP FEC, it can be either a - budnode or just an egress. If the Proxy LSR is a budnode, an MPLS - Proxy Ping Reply SHOULD be sent to the initiator with the Return Code - set to 3, "Reply router is egress for FEC", with Return Subcode set - to 0 and DS/DDMAPs only if the Proxy initiator requested information - to be returned in an MPLS Proxy Ping Reply. If the Proxy LSR is a - budnode but not requested to return an MPLS Proxy Ping Reply, the - Proxy LSR SHOULD send MPLS Echo Request packet(s) to the downstream - neighbors (no MPLS Echo Reply is sent to the Proxy Initiator to - indicate that the Proxy LSR is an egress). If the Proxy LSR is just - an egress, an MPLS Proxy Ping Reply SHOULD be sent to the initiator - with the Return Code set to 3, "Reply router is egress for FEC", and - Return Subcode set to 0. + bud node or just an egress. If the Proxy LSR is a bud node, a MPLS + Proxy Ping Reply SHOULD be sent to the initiator with the return code + set to 3 (Reply router is Egress for FEC) with return Subcode set to + 0. DS/DDMAPs are included only if the Proxy initiator requested + information to be returned in a MPLS Proxy Ping Reply. If the Proxy + LSR is a bud node but not requested to return an MPLS Proxy Ping + Reply, the Proxy LSR SHOULD send MPLS Echo Request packet(s) to the + downstream neighbors (no MPLS Echo Reply is sent to the Proxy + Initiator to indicate that the Proxy LSR is an egress). If the Proxy + LSR is just an egress, an MPLS Proxy Ping Reply SHOULD be sent to the + initiator with the Return Code set to 3, "Reply router is egress for + FEC", and Return Subcode set to 0. When the Proxy LSR is the egress of a MP2MP FEC, it can be either a - budnode or just an egress. LSP pings sent from a leaf of a MP2MP have - different behavior in this case. MPLS Echo Requests are sent to all - upstream/downstream neighbors. The Proxy LSRs need to be consistent - with this variation in behavior. If the Proxy LSR is a budnode or - just an egress, an MPLS proxy ping reply SHOULD be sent to the Proxy - Initiator with the return code set to 3, "Reply router is Egress for - FEC", with Return Subcode set to 0 and DS/DDMAPs included only if the - Proxy initiator requested information to be returned in a MPLS Proxy - Ping Reply. If the Proxy LSR is not requested to return information - in an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send MPLS Echo - Request packets to all upstream/downstream neighbors as would be done - when sourcing an LSP ping from a MP2MP leaf (no MPLS Echo Reply is - sent to the Proxy initiator indicating that the Proxy LSR is an - egress). + bud node or just an egress. LSP pings sent from a leaf of a MP2MP + have different behavior in this case. MPLS Echo Requests are sent to + all upstream/downstream neighbors. The Proxy LSRs need to be + consistent with this variation in behavior. If the Proxy LSR is a bud + node or just an egress, an MPLS Proxy Ping Reply SHOULD be sent to + the Proxy Initiator with the return code set to 3, "Reply router is + Egress for FEC", with Return Subcode set to 0 and DS/DDMAPs included + only if the Proxy initiator requested information to be returned in a + MPLS Proxy Ping Reply. If the Proxy LSR is not requested to return + information in an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send + MPLS Echo Request packets to all upstream/downstream neighbors as + would be done when sourcing an LSP ping from a MP2MP leaf (no MPLS + Echo Reply is sent to the Proxy initiator indicating that the Proxy + LSR is an egress). 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply - When the Proxy LSR is a transit or bud node, downstream maps corresponding to how the packet is transited cannot be supplied unless an ingress interface for the MPLS Echo Request is specified. Since this information is not available and all valid output paths are of interest, the Proxy LSR SHOULD include DS/DDMAP(s) to describe the entire set of paths that the packet can be replicated. This is similar to the case in which an LSP ping is initiated at the Proxy LSR. For mLDP, there is a DSMAP/DDMAP per upstream/downstream neighbor for MP2MP LSPs, or per downstream neighbor in the P2MP LSP case. @@ -511,22 +523,22 @@ corresponding to how the packet is transited cannot be supplied unless an ingress interface for the MPLS Echo Request is specified. Since this information is not available and all valid output paths are of interest, the Proxy LSR SHOULD include DS/DDMAP(s) to describe the entire set of paths that the packet can be replicated. This is similar to the case in which an LSP ping is initiated at the Proxy LSR. For mLDP, there is a DSMAP/DDMAP per upstream/downstream neighbor for MP2MP LSPs, or per downstream neighbor in the P2MP LSP case. - When the Proxy LSR is a bud node or egress in an MP2MP LSP or a - budnode in a P2MP LSP, an LSP ping initiated from the Proxy LSR would + When the Proxy LSR is a bud node or egress in an MP2MP LSP or a bud + node in a P2MP LSP, an LSP ping initiated from the Proxy LSR would source packets only to the neighbors but not itself, despite the fact that the Proxy LSR is itself an egress for the FEC. In order to match the behavior as seen from LSP Ping initiated at the Proxy LSR, the Proxy Reply SHOULD contain DSMAP/DDMAPs for only the paths to the upstream/downstream neighbors, but no DSMAP/DDMAP describing its own egress paths. The proxy LSR identifies that it's an egress for the FEC using a different Proxy Reply Return Code. The Proxy reply Return Code is either set to "Reply router has a mapping for the topmost FEC" or "Reply router is egress for the FEC". @@ -592,21 +605,21 @@ Proxy LSR introduces a Pad TLV such that size of the MPLS Echo Request (including any IP and UDP header) is zero padded to the specified MPLS payload size. The First Octet in Value part of the Pad TLV is set to 1, "Drop Pad TLV from Reply", the remaining Octets of the Value part of the Pad TLV is filled with zeros. If IP header is use to encapsulate in the MPLS Echo Request the DF bit MUST be set to one. The message is then encapsulated in a UDP packet. The source UDP port is copied from the Proxy Echo Parameters TLV. The destination port is - copied from the proxy ping request message. + copied from the MPLS Proxy Ping Request message. The source IP address is set to a routable address specified in the reply-to-address TLV or the source address of the received Proxy Request. Per usual the TTL of the IP packet is set to 1. If the Explicit Differentiated Services Code Point (DSCP) flag is set, the Requested DSCP byte is examined. If the setting is permitted then the DSCP byte of the IP header of the MPLS Echo Request message is set to that value. If the Proxy LSR does not permit explicit control for the DSCP byte, the MPLS Proxy Echo Parameters with the @@ -762,30 +776,30 @@ to request actions at the Proxy LSR. 0x01 Request for FEC Neighbor Address info When set, this requests that the Proxy LSR supply the Upstream and Downstream neighbor address information in the MPLS Proxy Ping Reply message. This flag is only applicable for the topmost FEC in the FEC stack if the FEC type corresponds with a P2MP or MP2MP LSP. The Proxy LSR MUST respond as applicable with Upstream Neighbor Address and - Downstream Neighbor Address TLV(s) in the MPLS proxy ping - reply message. The Upstream Neighbor Address TLV needs be + Downstream Neighbor Address TLV(s) in the MPLS Proxy Ping + Reply message. The Upstream Neighbor Address TLV needs be included only if there is an upstream neighbor. Similarly, one Downstream Neighbor Address TLV needs to be included for each Downstream Neighbor from which the LSR learned bindings. Setting this flag will cause the Proxy LSR to cancel sending any MPLS Echo Request. The initiator may use information - learned from the MPLS proxy ping reply that is sent instead + learned from the MPLS Proxy Ping Reply that is sent instead to generate subsequent proxy requests. 0x02 Request for Downstream Mapping When set, this requests that the Proxy LSR supply a Downstream Mapping TLV see [RFC4379] in the MPLS Proxy Ping Reply message. Either this flag may be set or the Request for Downstream Detailed Mapping flag may be set, but not both. @@ -795,24 +809,25 @@ Proxy Requests. 0x04 Request for Downstream Detailed Mapping When set, this requests that the Proxy LSR supply a Downstream Detailed Mapping TLV see [RFC6424] in the MPLS Proxy Ping Reply message. It's not valid to have Request for Downstream Mapping flag set when this flag is set. Setting this flag will cause the Proxy LSR to cancel sending an Echo request. The initiator may use information learned from the - MPLS proxy ping reply that is sent instead to generate + MPLS Proxy Ping Reply that is sent instead to generate subsequent proxy requests. 0x08 Explicit DSCP Request + When set, this requests that the Proxy LSR use the supplied "Rqst'd DSCP" byte in the Echo Request message TTL The TTL to be used in the label stack entry corresponding to the topmost FEC in the in the MPLS Echo Request packet. Valid values are in the range [1,255]. A setting of 0 SHOULD be ignored by the Proxy LSR. @@ -875,24 +890,26 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Type Type Type of Next Hop Addr Length IF Length 1 IPv4 Numbered 4 4 2 IPv4 Unnumbered 4 4 3 IPv6 Numbered 16 16 4 IPv6 Unnumbered 16 4 + 5 Reserved TBA-11 IPv4 Protocol Adj 4 0 TBA-12 IPv6 Protocol Adj 16 0 Note: Types 1-4 correspond to the types in the DS Mapping TLV. + They are expected to populated with information obtained through a previously returned DS Mapping TLV. Types and are intended to be populated from the local address information obtained from a previously returned Downstream Neighbor Address TLV(s)/Upstream Neighbor Address TLV. Next Hop IP Address A next hop address that the echo request message is to @@ -1010,47 +1028,50 @@ The local address used in the protocol adjacency exists by which the label for this FEC was exchanged. 6. Security Considerations The mechanisms described in this document are intended to be used within a Service Provider network and to be initiated only under the authority of that administration. If such a network also carries Internet traffic, or permits IP access - from other administrations, MPLS proxy ping message SHOULD be + from other administrations, MPLS Proxy Ping message SHOULD be discarded at the points that where the IP packet is received from the - other administration. This can be accomplished by filtering on source - address or by filtering all MPLS ping messages on UDP port. + other administrations. This can be accomplished by filtering on + source address or by filtering all MPLS ping messages on UDP port. - Any node which acts as a Proxy node SHOULD validate requests against - a set of valid source addresses. An implementation MUST provide such + Any node which acts as a Proxy LSR SHOULD validate requests against a + set of valid source addresses. An implementation MUST provide such filtering capabilities. MPLS Proxy Ping Request messages are IP addressed directly to the - Proxy node. If a node receives an MPLS Proxy Ping message via IP or - Label TTL expiration, it MUST NOT be acted upon. + Proxy LSR. If a Proxy LSR receives an MPLS Proxy Ping message via + expiration of the IP or Label Stack Entry TTL, it MUST NOT be acted + upon. If an MPLS Proxy Ping Request IP source address is not IP reachable by the Proxy LSR, the Proxy Request MUST NOT be acted upon. MPLS Proxy Ping Requests are limited to making their request via the specification of a FEC. This ensures that only valid MPLS Echo Request messages can be created. No label spoofing attacks are possible. 7. Acknowledgements - The authors would like to thank Nobo Akiya, Adrian Farrel, Tom Taylor - and Warren Kumari for their detailed review and insightful comments. + The authors would like to thank Nobo Akiya, Adrian Farrel, Tom Yu, + Tom Taylor and Warren Kumari for their detailed review and insightful + comments. 8. IANA Considerations + This document makes the following assignments (pending IANA action) MPLS LSP Ping Message Types Type Value Field ---- ----------- TBA-1 MPLS Proxy Ping Request TBA-2 MPLS Proxy Ping Reply TLVs @@ -1064,58 +1085,93 @@ Return Code [pending IANA assignment] Value Meaning ----- ------- TBA-7 Proxy Ping not authorized. TBA-8 Proxy Ping parameters need to be modified. TBA-9 MPLS Echo Request Could not be sent. TBA-10 Replying router has FEC mapping for topmost FEC. - Downstream Address Mapping Registry [pending IANA assignment] - - Value Meaning - ----- ------- - TBA-11 IPv4 Protocol Adj - TBA-12 IPv6 Protocol Adj - 8.1. Proxy Echo Parameters Sub-TLVs The IANA will create and maintain this new registry for Proxy Echo Parameters Sub-TLV's. Assignments will use the same rules spelled out in sec 7.2 of [RFC4379]. Sub-TLV Type Meaning ----------- ------- 0 Reserved TBA-13 Next Hop -9. References +8.2. Downstream Address Mapping Registry [pending IANA assignment] + This document makes the following assignments in the Downstream + Address Mapping Registry(pending IANA assignment). This document + updates the registry defined by [RFC6426], modifying the allocation + procedures. + + The allocation procedures of Downstream Mapping Address Type Registry + is changed to read 'Standards action - each time a code point is + assigned from this registry, unless the same registration is made in + both registries, the corresponding Next Hop Address Type Registry + must be Marked "Reserved". + + Value Meaning K Octets + ----- ------- -------- + + TBA-11 Reserved N/A [this doc] + TBA-12 Reserved N/A [this doc] + +8.3. Next Hop Sub-TLV Address Type Registry + + IANA is requested to create a new registry called "Next Hop Address + Type Registry". The allocation policy for this registry is + "Standards action". Further, each time a code point is assigned from + this registry, unless the same registration is made in both + registries, the corresponding Downstream Address Mapping Registry + must be Marked "Reserved". The initial allocations are: + + Type Type of Next Hop Addr Length IF Length Reference + + 1 IPv4 Numbered 4 4 [RFC4379] + 2 IPv4 Unnumbered 4 4 [RFC4379] + 3 IPv6 Numbered 16 16 [RFC4379] + 4 IPv6 Unnumbered 16 4 [RFC4379] + 5 Reserved [this doc] + TBA-11 IPv4 Protocol Adj 4 0 [this doc] + TBA-12 IPv6 Protocol Adj 16 0 [this doc] + x-255 Unassigned + +9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, November 2011. [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011. + [RFC6426] Gray, E., Bahadur, N., Boutros, S., and Aggarwal, R., + "MPLS On-Demand Connectivity Verification and Route + Tracing", RFC 6426, November 2011. + [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and Delord, S., "Return Path Specified Label Switched Path (LSP) Ping", RFC 7110, January 2014. 9.2. Informative References [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.