Network Working Group George Swallow Internet Draft Cisco Systems, Inc. Category: Standards Track Expiration Date: October 2007 Thomas D. Nadeau Cisco Systems, Inc. Rahul Aggarwal Juniper Networks, Inc. April 2007 Connectivity Verification for Multicast Label Switched Paths draft-ietf-mpls-mcast-cv-00.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 other groups may also distribute working documents as Internet- Drafts. 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." 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 Abstract Requirements for MPLS P2MP LSPs extend to hundreds or even thousands of endpoints. This document defines a more scalable approach to verifying connectivity for P2MP LSPs. Swallow, et al. Standards Track [Page 1] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 Contents 1 Introduction .............................................. 3 1.1 Conventions ............................................... 3 2 Overview .................................................. 3 3 Connectivity Verification Bootstrapping and Maintenance ... 4 3.1 Bootstrap and Maintenance Procedures at the Root .......... 4 3.1.1 Special Considerations for RSVP-TE P2MP Tunnels ........... 5 3.1.2 Special Considerations for mLDP P2MP Tunnels .............. 5 3.2 Procedures at an Egress ................................... 6 3.2.1 Creating Egress Connectivity Verification State ........... 6 3.2.2 Updating Egress Connectivity Verification State ........... 7 3.2.3 CV Session State Machine .................................. 7 4 Connectivity Verification Session Object .................. 7 4.1 Administratively Down IPv4 Nodes .......................... 8 4.2 Administratively Down IPv6 Nodes .......................... 8 5 Security Considerations ................................... 9 6 IANA Considerations ....................................... 9 7 Acknowledgments ........................................... 9 8 References ................................................ 10 8.1 Normative References ...................................... 10 8.2 Informative References .................................... 10 9 Authors' Addresses ........................................ 11 Swallow, et al. Standards Track [Page 2] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 1. Introduction Requirements for Multi-protocol Label Switching (MPLS) Point-to-mul- tipoint (P2MP) Label Switched Paths (LSPs) call for scaling up to hundreds or even thousands of endpoints. Existing tools such as those defined in [RFC4379] and [MPLS-BFD] generally require explicit acknowledgment to each connectivity probe. Such explicit acknowledg- ments adversely affect the scalability and/or practicality of per- forming connectivity verification. That is, the response load at the root would either be overwhelming unless the probing was done infre- quently. This document defines a more scalable approach to monitor- ing P2MP LSP connectivity. MPLS Echo Request/Reply messages [RFC4379] are used to bootstrap a Bi-directional Forwarding Detection (BFD) session across the P2MP LSP in a manner similar to "BFD For MPLS LSPs" [MPLS-BFD]. The actual monitoring uses extensions to BFD defined in [BFD-MCST]. 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]. Based on context the terms leaf, egress and receiver are used some- what interchangeably. The first two are exactly the same. Egress is used where consistency with [RFC4379] was deemed appropriate. Receiver is used in the context of receiving protocol messages. 2. Overview In order to scale to large numbers of leaves and to be able to verify connectivity on a frequent basis the protocol defined herein uses BFD packets as unidirectional probes. As specified in [BFD-MCST] BFD packets are sent by the root at a fixed minimum interval. The leaves receive BFD packets and declare a connectivity fault if more than a fixed number of BFD messages are missed. The session is bootstrapped by an MPLS Echo Request/Reply message exchange. The root periodically sends MPLS Echo Request messages containing a Connectivity Verification Session object which is defined in section 3.1. The Echo Request message contains a FEC stack to identify the LSP. This serves to bind the FEC to a BFD dis- criminator. Swallow, et al. Standards Track [Page 3] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 Further discussion on the necessity of bootstrapping the BFD session with with MPLS Echo Request/Reply messages can be found in section 3.2 of [MPLS-BFD]. 3. Connectivity Verification Bootstrapping and Maintenance The root of the multicast tree initiates Connectivity Verification and is responsible for most of the parameters involved in the Connec- tivity Verification (CV) Session. These parameters are communicated both through MPLS echo request messages and through BFD. The primary role of of the echo request message is to provide the binding between the root's address and chosen BFD discriminator and a particular FEC. It further enables the root to scope the session to a subset of leaves. It also provides a facility for declare some leaves adminis- tratively down while maintaining the CV session for the balance of the leaves. The balance of the session parameters are communicated through BFD. 3.1. Bootstrap and Maintenance Procedures at the Root The root first selects a discriminator and an IP destination address to be used both in the BFD packets and in the Connectivity Verifica- tion Session object. Prior to sending an MPLS Echo Request message, the root SHOULD begin sending BFD packets with the selected Discrimi- nator in the My Discriminator field and destination IP address in- band of the subject LSP. Failure to do this could result in false alarms. The root then bootstraps the CV Sessions by creating an MPLS Echo Request message containing a Connectivity Verification Session object and a FEC stack which specifies the LSP for which connectivity veri- fication is desired. The Connectivity Verification Session object MUST contain the selected discriminator and destination IP address. For IPv4 the address MUST be in the range 127/8; for IPv6 the address MUST be in the range 0:0:0:0:0:FFFF:127/104. The Lifetime SHOULD be set to a large value as compared to the BFD Detection Time. Echo reply messages can be jittered by using the Echo Jitter object defined in [[MCSTPING]. the jitter time is set to value that is a function of the rate at which the root is able to process responses and the expected number of responders to this particular message. Exactly how values are chosen is implementation and platform Swallow, et al. Standards Track [Page 4] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 dependent. As such, the exact setting of this interval is beyond the scope of this document. The source and destination IP address of the MPLS echo request packet MUST be the same as those used in the BFD packets. The message is then sent in-band of the LSP. The root (assuming the root does not want the session to time-out) MUST refresh the session within Lifetime milliseconds. It is RECOM- MENDED that the root refresh the CV Session at approximately one third of the Lifetime. If the root wishes to increase the Lifetime, it should behave as if it were first bootstrapping the session. That is it should seek Echo reply messages from all receivers. If the entire CV Session is administratively taken down, this SHOULD be handled through BFD. If, however, a subset of the egress nodes is to be administratively taken down, this is accomplished by including the Administratively Down Nodes sub-object listing the subject nodes. This list may be modified on any refresh message to indicate addi- tional nodes being taken down or to indicate certain nodes as no- longer administratively down. Note that refresh messages MAY be sent at any time to accomplish this. 3.1.1. Special Considerations for RSVP-TE P2MP Tunnels For RSVP P2MP tunnels the root knows all of the leaves. When boot- strapping a session, the root can know when all the leaves have responded. Suppose that an initial bootstrap message has been sent and sufficient time for responses have been allowed. If the root has not received MPLS Echo Reply messages from all of the leaves, the root MAY send a subsequent bootstrap message immediately using the scoping techniques of [MCSTPING] to limit the responses. If a new leaf is added to the tree, the root MAY send a refresh mes- sage immediately. Further it MAY use the scoping techniques of [MCSTPING] to limit the response to just the new leaf. 3.1.2. Special Considerations for mLDP P2MP Tunnels For Multicast LDP P2MP tunnels the root generally does not know all of the leaves. It is therefore RECOMMENDED that the initial boot- strapping messages be retransmitted several times at relatively short intervals. The number of times SHOULD be equal to or greater than the value of bfd.DetectMult of the associated BFD MultipointHead Swallow, et al. Standards Track [Page 5] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 session. Note that the root can learn who the leaves are from the MPLS Echo Reply messages. It is RECOMMENDED that the root keep a list of active leaves. When the any of the parameters in section 3.2 above are changed, the root can then use the technique in section 3.2.1 to ensure that state is updated, noting however, that some leaves may have ceased connectivity to the tree, while others may have joined. 3.2. Procedures at an Egress [Note: this section needs to be brought into in sync with [BFD-MCST]] BFD packets which have the M bit set and are addressed to IPv4 addresses in the range 127/8 or IPv6 addresses in the range 0:0:0:0:0:FFFF:127/104 SHOULD be ignored if no MPLS Echo Request has been received containing the associated IP source address and dis- criminator combination. When a node receives a MPLS Echo Request containing a Connectivity Verification object, it begins by processing the message as it would any other MPLS Echo Request message. If the result of that process- ing is error free and this node is an egress for the FEC at the bot- tom of the FEC stack, it checks to see if it has CV session state matching the source IP address, discriminator and FEC stack. If not it creates state as specified in section 3.2.1 below. If it does it updates that state as specified in section 3.2.2. Normal response processing for the received MPLS Echo is then done. 3.2.1. Creating Egress Connectivity Verification State CV session state is created keyed on the source IP address and Dis- criminator value. This state is set to expire in Lifetime millisec- onds. The session is considered to have expired if not refreshed prior to the expiration of this timer. Included in this state is the FEC and CV Session state, initially set to Init. The egress SHOULD now process BFD packets with this source IP address and Discriminator value. When a BFD packet is received that matches the source IP address and Discriminator it is processed and a BFD session is created. The BFD session is linked to this CV state. In particular the CV session is informed of the BFD state transitions. The CV Session state is changed to UP. Swallow, et al. Standards Track [Page 6] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 3.2.2. Updating Egress Connectivity Verification State [Note, this section will be updated when the Egress CV Session State Machine is added]. If a Connectivity Verification Session object is received which matches the Source_IP_Addr, Discriminator and FEC Stack of existing CV state the Lifetime is reset and the message is examined to deter- mine if there have been any changes in parameters. If the IP address of the egress has been added to the Administratively down nodes, the egress MUST change the CV session state to Administratively Down. If the IP address of the egress has been removed from the Administra- tively Down nodes, then if the BFD session state is Down or the BFD session has been deleted, the CV state is set to INIT; if the BFD session state is UP the CV session state is set to UP. 3.2.3. CV Session State Machine [To be written] 4. Connectivity Verification Session Object The Connectivity Verification Session object is used to notify leaves that connectivity verification will be performed on the LSP and to set the connectivity verification parameters. The Connectivity Verification Session object has the following for- mat: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Objects | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Swallow, et al. Standards Track [Page 7] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 Discriminator The unique, nonzero discriminator value generated by the transmitting system, which will be used to identify this BFD session. Lifetime This is the minimum period before a refresh message is sent in milliseconds. Sub-Objects Two sub-objects are defined Sub-Type Length Value Field -------- ------ ----------- 1 4+ Administratively Down IPv4 Nodes 2 16+ Administratively Down IPv6 Nodes 4.1. Administratively Down IPv4 Nodes The Administratively Down IPv4 Nodes sub-object is used to suppress alarms from specific nodes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional IPv4 Address | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2. Administratively Down IPv6 Nodes The Administratively Down IPv6 Nodes sub-object is used to suppress alarms from specific nodes. Swallow, et al. Standards Track [Page 8] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix | | (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional IPv6 Address | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Security Considerations Security considerations discussed in [BFD], [BFD-MHOP] and [RFC4379] apply to this document. 6. IANA Considerations This document makes the following codepoint assignments from the LSP Ping Object Type registry (pending IANA action): Object Codepoint Sub-objects Connectivity Verification Session tba Administratively Down IPv4 Nodes 1 Administratively Down IPv6 Nodes 2 7. Acknowledgments The authors would like to thank Dave Katz, Dave Ward, and Vanson Lim for their comments and suggestions. Swallow, et al. Standards Track [Page 9] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 8. References 8.1. Normative References [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [BFD-MCST] Katz, D. and D. Ward, "BFD for Multipoint Networks", draft-katz-ward-bfd-multipoint-00.txt, February 2007. [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", draft-ietf-bfd-base-05.txt, June 2006. [BFD-MHOP] D. Katz, D. Ward, "BFD for Multihop Paths", draft-ietf-bfd-multihop-04.txt, June 2006. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MCSTPING] Farrel, A. et al, "Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic Engineering - Extensions to LSP Ping", draft-ietf-mpls-p2mp-lsp-ping-02.txt, September 2006. 8.2. Informative References [MPLS-BFD] Aggarwal, R., et al., "BFD For MPLS LSPs", draft-ietf-bfd-mpls-03.txt, June 2006. Swallow, et al. Standards Track [Page 10] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 9. Authors' Addresses George Swallow Cisco Systems, Inc. Email: swallow@cisco.com Tom Nadeau Cisco Systems, Inc. Email: tnadeau@cisco.com Rahul Aggarwal Juniper Networks, Inc. Email: rahul@juniper.net Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assur- ances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Swallow, et al. Standards Track [Page 11] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 Full Copyright Notice Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Swallow, et al. Standards Track [Page 12] Internet Draft draft-ietf-mpls-mcast-cv-00.txt April 2007 Notes: Destination address in CV object The destination address is included to allow out of band pings to solicit responses from individual destinations. Is this desir- able? Alarm mode Would it be useful to have any configuration of alarm mode? I.e. syslog vs NMS. Notification back to the root is covered in BFD-MCST Think about later: Finer control on how individual nodes alarm Individual tails could be configured via LSP Ping so that they never send BFD control packets to the head, even when the head wishes notification of path failure from the tail. Such tails will never be known to the head, but will still be able to detect multipoint path failures from the head. Is such a thing useful? Automatic authentication configuration (is that an oxymoron?) If authentication is in use, all tails must be configured to have a common authentication key in order to receive the multipoint BFD Control packets. The bootstrap *could* be used to configure the BFD auth info, but I'm not at all sure that can be done securely. Updating section needs to have change of FEC covered. Configuration at the egress needs to be discussed. Swallow, et al. Standards Track [Page 13]