Network Working Group                                     George Swallow
Internet Draft                                       Cisco Systems, Inc.
Category: Standards Track
Expiration Date: April 2007
                                                        Thomas D. Nadeau
                                                     Cisco Systems, Inc.

                                                          Rahul Aggarwal
                                                  Juniper Networks, Inc.

                                                            October 2006


      Connectivity Verification for Multicast Label Switched Paths


                   draft-swallow-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-swallow-mpls-mcast-cv-00.txt       October 2006


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  ..............   6
 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  ........................................................   7
 4      Connectivity Verification Session Object  ..................   7
 4.1    IPv4 Connectivity Verification Session Object  .............   7
 4.1.1  Included IPv4 Nodes  .......................................   8
 4.1.2  Excluded IPv4 Nodes  .......................................   9
 4.1.3  Administratively Down IPv4 Nodes  ..........................   9
 4.2    IPv6 Connectivity Verification Session Object  .............  10
 4.2.1  Included IPv6 Nodes  .......................................  11
 4.2.2  Excluded IPv6 Nodes  .......................................  11
 4.2.3  Administratively Down IPv6 Nodes  ..........................  12
 5      Security Considerations  ...................................  12
 6      IANA Considerations  .......................................  13
 7      Acknowledgments  ...........................................  13
 8      References  ................................................  13
 8.1    Normative References  ......................................  13
 8.2    Informative References  ....................................  14
 9      Authors' Addresses  ........................................  14





















Swallow, et al.              Standards Track                    [Page 2]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 2006


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-swallow-mpls-mcast-cv-00.txt       October 2006


   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 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 administratively
   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 relatively large value as compared to
   the BFD Detect Time.

   The CV Session MAY be scoped to a subset of leaves by including one
   of either the Excluded Nodes or Included Nodes sub-object.

   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



Swallow, et al.              Standards Track                    [Page 4]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 2006


   and the expected number of responders to this particular message.
   Exactly how values are chosen is implementation and platform depen-
   dent.  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.










Swallow, et al.              Standards Track                    [Page 5]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 2006


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 at Detection_Multiple times at a
   relatively short intervals.

   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 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 discriminator 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 that the node is an egress for the FEC at the bottom of the
   FEC stack, it checks to see if it has 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

   If the message contains an Included Nodes sub-object which does not
   list the egress or contains an Excluded Nodes sub-object which lists
   the egress, no action is taken.  Otherwise, state is created keyed on
   the source IP address and Discriminator value.  This state is set to
   expire in Lifetime milliseconds.  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



Swallow, et al.              Standards Track                    [Page 6]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 2006


   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.


3.2.2. Updating Egress Connectivity Verification State

   [Note, this section will be updated when the CV Session State Machine
   is added].

   If an 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.

   If the egress has been removed from the Included Nodes sub-object or
   added to the Excluded Nodes sub-object then the BFD session is termi-
   nated and the Connectivity Verification state is removed.


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.


4.1. IPv4 Connectivity Verification Session Object

   The IPv4 Connectivity Verification Session object has the following
   format:







Swallow, et al.              Standards Track                    [Page 7]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 2006


      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                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Destination Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Lifetime                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Sub-TLVs                            |
     .                                                               .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Discriminator

         The unique, nonzero discriminator value generated by the
         transmitting system, which will be used to identify this BFD
         session.

      Destination Address

         The IPv4 Destination Address that will be used in the BFD
         packets sent.  Normally this is an address from the range 127/8.

      Lifetime

         This is the minimum period before a refresh message is sent in
         milliseconds.

      Sub-TLVs

         Three sub-TLVs are defined

         Sub-Type      Length          Value Field
         --------      ------          -----------
                1          4+          Included IPv4 Nodes
                2          4+          Excluded IPv4 Nodes
                3          4+          Administratively Down IPv4 Nodes


4.1.1. Included IPv4 Nodes

   The Included IPv4 Nodes sub-object scopes to message to bootstrap all
   nodes listed in the Included IPv4 Nodes sub-object.  This sub-object
   MUST NOT be used in combination with the Excluded IPv4 Nodes sub-
   object.



Swallow, et al.              Standards Track                    [Page 8]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 2006


      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.1.2. Excluded IPv4 Nodes

   The Excluded IPv4 Nodes sub-object scopes the message to bootstrap
   all nodes not listed in the Excluded IPv4 Nodes sub-object.  This
   sub-object MUST NOT be used in combination with the Included IPv4
   Nodes sub-object.

      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.1.3. 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                     |
     .                                                               .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Swallow, et al.              Standards Track                    [Page 9]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 2006


4.2. IPv6 Connectivity Verification Session Object

   The IPv6 Connectivity Verification Session object 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Discriminator                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                     Destination Address                       |
     +                                                               +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Lifetime                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Sub-TLVs                            |
     .                                                               .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Discriminator

         The unique, nonzero discriminator value generated by the
         transmitting system, which will be used to identify this BFD
         session.

      Destination Address

         The IPv6 Destination Address that will be used in the BFD
         packets sent.  Normally this is an address from the range
         0:0:0:0:0:FFFF:127/104.

      Lifetime

         This is the minimum period before a refresh message is sent in
         milliseconds.









Swallow, et al.              Standards Track                   [Page 10]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 2006


      Sub-TLVs

         Three sub-TLVs are defined

         Sub-Type      Length          Value Field
         --------      ------          -----------
                1         16+          Included IPv6 Nodes
                2         16+          Excluded IPv6 Nodes
                3         16+          Administratively Down IPv6 Nodes


4.2.1. Included IPv6 Nodes

   The Included IPv6 Nodes sub-object scopes to message to bootstrap all
   nodes listed in the Included IPv6 Nodes sub-object.  This sub-object
   MUST NOT be used in combination with the Excluded IPv6 Nodes sub-
   object.

      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                     |
     .                                                               .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



4.2.2. Excluded IPv6 Nodes

   The Excluded IPv6 Nodes sub-object scopes the message to bootstrap
   all nodes not listed in the Excluded IPv6 Nodes sub-object.  This
   sub-object MUST NOT be used in combination with the Included IPv6
   Nodes sub-object.











Swallow, et al.              Standards Track                   [Page 11]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 2006


      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                     |
     .                                                               .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.2.3. Administratively Down IPv6 Nodes

   The Administratively Down IPv6 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IPv6 prefix                          |
     |                          (16 octets)                          |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Additional IPv6 Address                     |
     .                                                               .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



5. Security Considerations

      Security considerations discussed in [BFD], [BFD-MHOP] and
   [RFC4379]
      apply to this document.










Swallow, et al.              Standards Track                   [Page 12]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 2006


6. IANA Considerations

   This document makes the following codepoint assignments from the LSP
   Ping Object Type registry (pending IANA action):

       Object                                      Codepoint
          Sub-object

       IPv4 Connectivity Verification Session         tba
          Included IPv4 Nodes                          1
          Excluded IPv4 Nodes                          2
          Administratively Down IPv4 Nodes             3
       IPv6 Connectivity Verification Session         tba
          Included IPv6 Nodes                          1
          Excluded IPv6 Nodes                          2
          Administratively Down IPv6 Nodes             3



7. Acknowledgments

   The authors would like to thank Dave Katz, Dave Ward, and Vanson Lim
   for their comments and suggestions.



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 and Multicast
              Networks", draft-katz-ward-bfd-multipoint-00.txt, October
              2006.

   [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



Swallow, et al.              Standards Track                   [Page 13]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 2006


              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.




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



Copyright Notice

   Copyright (C) The Internet Society (2006).  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

   April 2007






Swallow, et al.              Standards Track                   [Page 14]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt       October 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.

   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
   assurances 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 15]