Network Working Group Z. Zhang Internet-Draft Juniper Networks, Inc. Updates: 3032 (if approved) June 30, 2015 Intended status: Standards Track Expires: January 1, 2016 MPLS ICMP for BIER Payload draft-zzhang-mpls-icmp-bier-01.txt Abstract This document specifies an optional extension to generate ICMP messages for BIER packets transported over LSPs. Requirements Language 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 RFC2119. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." This Internet-Draft will expire on January 1, 2016. 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 carefully, as they describe your rights and restrictions with respect Zhang Expires January 1, 2016 [Page 1]
Internet-Draft mpls-icmp-bier June 2015 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Speficications . . . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction RFC3032 specifies that an LSR may generate ICMP messages if the payload is IPv4 or IPv6. Normally the ICMP messages are label switched using the original label stack, and the egress LSR will then forward the the messages to the source of the packet. BIER [wijnands-bier-architecture] is a new multicast forwarding architecture and [kumarzheng-bier-ping] specifies ping/traceroute procedures for BIER. BIER traceroute uses the same TTL-expiration principle of IPv4/IPv6 unicast traceroute. A BFR (a router that supports BIER) may get a traceroute probe message whose TTL just expired at this hop and may send back a response, allowing a BFIR (ingress BFR) to gather the paths that a BIER packet traverses. It's possible that a BIER packet is transported over an LSP between two BFRs. If Uniform Model for TTL is used for the LSP, when the ingress LER for the LSP put the BIER packet with a preceeding BIER label into the tunnel, the TTL from the BIER label is copied to the outgoing label for the LSP. As a result, the TTL expiration may happen on an LSR on the LSP, who will silently drop the packet. This TTL expiration could easily happen with traceroute, because the BFR that initiates the tracing will increase the TTL to be used one by one to discover the path. The silent drop by an LSR is therefore undesired. If the LSR can generate an ICMP message for the TTL expiration, label switch it to the LER that advertised the inner most label just like in the IPv4/IPv6 case, that LER, which is is a BFR, will be able to process the TTL expiration for BIER traceroute purpose. Zhang Expires January 1, 2016 [Page 2]
Internet-Draft mpls-icmp-bier June 2015 Note that in IPv4/IPv6 case, the generated ICMP message is addressed to the packet's source address and the message will be transparently routed back to the source of the packet by the LER that advertised the inner most label in the stack. For BIER, the ICMP message is to be processed by the LER that advertised the inner most label. Therefore, the destination address of the ICMP message is set to local host address 127.0.0.1 or ::1, depending on if the MPLS infrastructure is based on IPv4 or IPv6. In the following example diagram, there is an ingress BFR (BFIR), an egress BFR (BFER), and two transit BFRs (BFR1/BFR2) separated by two non-BFRs. When BFIR sends a BIER packet, BFR1 will put the BIER packets into a tunnel between BFR1 and BFR2. If Uniform model is used on BFR1, the tunneled packet could have TTL expiration on non- BFR1. When that happens, non-BFR1 will generate an ICMP message addressed to local host address 127.0.0.1 or ::1, and label switch to BFR2. BFR2 will then process the ICMP message and may send appropriate response to the BFIR. BFIR --- BFR1 --- non-BFR1 --- non-BFR2 --- BFR2 --- BFER \...........tunnel................../ ^ | ttl-expiration on non-BFR1; generated ICMP message label switched to, and processed by BFR2 Figure 1 In theory, it is possible that the outer LSP for which the LSR is having TTL expiration is the base LSP for a stacked LSP and the latter uses a differently versioned IP infrastructure, so the version of the ICMP message may be chosen incorrectly. In reality, this is unlikely to happen because the label stack is to transport BIER packets between two BFRs that are in the same IGP domain. Even if it does happen, it is likely that the LER is able to process both ICMP and ICMPv6 messages, and even if the LER is not able to process the incoming ICMP/ICMPv6 message it can discard the message silently - not much different from the LSR not generating the message the first place. It is expected that the BIER encapsulation header will start with a 4-bit nibble with a unique value that suggests that it is a BIER packet. This specification focuses on ICMP message generated for TTL expiration. Other types of ICMP messages are out of the scope at this time. Zhang Expires January 1, 2016 [Page 3]
Internet-Draft mpls-icmp-bier June 2015 2. Speficications When an LSR experiences a TTL expiration for a labeled packet and the first 4-bit nibble is X [TBD], the LSR MAY generate an ICMP message if the MPLS infrastructure is IPv4 based, or an ICMPv6 message if the MPLS infrastructure is IPv6 based. The destination of the message is 127.0.0.1 in case of IPv4 or ::1 in case of IPv6. The source of the message is a routable address of the LSR. The LSR, if it supports BIER, MAY further check the BIER payload type. If the "proto" field of the BIER header is "BIER OAM", the LSR SHOULD generate an ICMP or ICMPv6 message. To differentiate from ICMP/ICMPv6 messages generated for IPv4/IPv6 playloads, the following message types are defined: ICMP messages: Type TBD1: TTL expired in tunnel ICMPV6 messages: Type TBD2: TTL expired in tunnel Alternatively, same message types but different code could be used to differentiate from IPv4/IPv6 payload triggered messages. [This will be decided based on WG input] Except for the differences mentioned above in message type/code, destination address, and ICMP/ICMPv6 choice based on MPLS infrastructure type, the ICMP/ICMPv6 messages are constructed following existing procedures for IPv4/IPv6 payload. The generated messages are label switched using the invoking packet's original label stack minus the inner most label. The original inner most label for a BIER packet is a BIER label indicating that the payload type is BIER, so it must not be used for switching the generated ICMP/ICMPv6 messages, which are not BIER packets. For a true BIER packet, the next inner most label is for the LSP terminating at the BFR that advertised the inner most label, so the original label stack minus the inner most label should get the generated ICMP/ICMPv6 message to the right place for further processing. For the example in Figure 1, when non-BRF1 experiences a TTL-expriation for a tunneled BIER packet, the label stack could be <tunnel label, BIER label>, where the tunnel label is advertised by non-BFR2 and the BIER label is advertised by BFR2. With the BIER label removed, the resulting label stack <tunnel label> will get the generated ICMP message to BFR2 for further processing. The LER that originated the inner most label for the generated messages will receive the ICMP/ICMPv6 messages, which is addressed to the local host, and process the messages locally. Zhang Expires January 1, 2016 [Page 4]
Internet-Draft mpls-icmp-bier June 2015 How the messages are processed is outside of the scope of this document, but in general the new ICMP message type/code causes the LER to examine the original packet header that is enclosed in the ICMP/ICMPv6 message and act accordingly, e.g., forward to BIER OAM module for further processing. Because a non-BIER packet may be mistaken as a BIER packet (if the first nibble happens to be match), the receiving BFR MUST check the label stack included in the ICMP/ ICMPv6 message to make sure that the inner most label is a BIER label that it advertised. It's possible that an IPv4 LER cannot process an incoming ICMPv6 message, or vice versa. It is also possible that an LER cannot recognize the new message type/code. In these cases, it simply discard the message. 3. IANA Considerations This document requests IANA to assigna a new message type in ICMP and ICMPv6 Parameters registries respectively. 4. Security Considerations This document does not introduce new security risks, compared to generating ICMP messages for labeled IP packets. 5. Acknowledgements The author thanks Eric Rosen, Ronald Bonica for their review, comments, and suggestions. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007. Zhang Expires January 1, 2016 [Page 5]
Internet-Draft mpls-icmp-bier June 2015 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007. 6.2. Informative References [I-D.ietf-bier-architecture] Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast using Bit Index Explicit Replication", draft-ietf-bier-architecture-00 (work in progress), April 2015. [I-D.kumarzheng-bier-ping] Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., and G. Mirsky, "BIER Ping and Trace", draft-kumarzheng- bier-ping-00 (work in progress), March 2015. Author's Address Zhaohui Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 EMail: zzhang@juniper.net Zhang Expires January 1, 2016 [Page 6]