Subject: [mpls] George Swallow: Please post the enclosed mcast ping draft

From: George Swallow <[email-masked]>
Date: Tue, 20 Jun 2006 13:04:40 -0400

Folks -

I was running off to my niece's wedding when I tried to post this.
But as you can see I didn't type the whole address.

I'll put it on the MPLS agenda time permitting.

...George

Subject: Please post the enclosed mcast ping draft
From: George Swallow <[email-masked]>
To: internet-drafts
Cc: tnadeau
Date: Sat, 17 Jun 2006 17:36:04 -0400

thanks,

...George

========================================================================


Network Working Group                                     George Swallow
Internet Draft                                       Cisco Systems, Inc.
Category: Standards Track
Expiration Date: December 2006
                                                              Tom Nadeau
                                                     Cisco Systems, Inc.

                                                               June 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.  Note that while this approach
   was developed in response to the multicast scalability problem, it
   can be applied to P2P LSPs as well.

Swallow & Nadeau             Standards Track                    [Page 1]


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

Contents

 1      Introduction  ..............................................   3
 1.1    Conventions  ...............................................   3
 1.2    Terminology  ...............................................   3
 2      Overview  ..................................................   3
 3      Connectivity Verification Bootstrapping  ...................   4
 3.1    Connectivity Verification Session Object  ..................   4
 3.2    Bootstrap and Maintenance Procedures at the Root  ..........   5
 3.2.1  Special Considerations for RSVP-TE P2MP Tunnels  ...........   6
 3.2.2  Special Considerations for mLDP P2MP Tunnels  ..............   6
 3.3    Bootstrapping Proceedures at an Egress  ....................   7
 3.3.1  Creating Egress Connectivity Verification State  ...........   7
 3.3.2  Updating Egress Connectivity Verification State  ...........   7
 4      MPLS Connectivity Verification Probing  ....................   8
 4.1    MPLS Connectivity Verification Probe  ......................   8
 4.2    Sending MPLS Connectivity Verification Probes  .............   9
 4.3    Receiving MPLS Connectivity Verification Probes  ...........   9
 4.4    MPLS Connectivity Verification UDP Port  ...................   9
 5      Multicast LDP FEC Stack Sub-object  ........................   9
 6      Security Considerations  ...................................  11
 7      IANA Considerations  .......................................  11
 8      Acknowledgments  ...........................................  11
 9      References  ................................................  11
 9.1    Normative References  ......................................  11
 9.2    Informative References  ....................................  12
10      Authors' Addresses  ........................................  12

Swallow & Nadeau             Standards Track                    [Page 2]


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

1. Introduction

   Requirements for MPLS P2MP LSPs extend to hundreds or even thousands
   of endpoints.  If a protocol required explicit acknowledgments to
   each probe for connectivity verification, the response load at the
   root would be overwhelming.

   This document defines a more scalable approach to monitoring P2MP LSP
   connectivity.  Note that while this approach was developed in
   response to the multicast scalability problem, it can be applied to
   P2P LSPs as well.

   MPLS Echo Request/Response messages [RFC4379] are used to bootstrap
   the monitoring mechanism in a manner similar to "BFD For MPLS LSPs"
   [MPLS-BFD].  The actual monitoring is done with MPLS Connectivity
   Verification Probes, which are defined herein.

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

1.2. Terminology

   Although the techniques of this document may be applied to P2P LSPs,
   terms applicable to P2MP LSPs are used throughout.  Based on context
   the terms leaf, egress and receiver are used somewhat interchange-
   ably.  The first two are exactly the same.  Egress is used where con-
   sistency 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 uses a unidirectional
   probe.  The probe message, the MPLS Connectivity Verification Probe,
   is defined in section 4.1.  Probes are sent by the root at a fixed
   minimum interval.  The leaves receive probes and declare a connectiv-
   ity fault if more than a fixed number of probe messages are missed.
   Probing is discussed in section 4.

   The session is bootstrapped with MPLS Echo Request/Response messages.

Swallow & Nadeau             Standards Track                    [Page 3]


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

   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 also contains a FEC stack to identify
   the LSP.  For mLDP P2MP LSPs a new FEC sub-TLV is defined in section
   5.  Bootstrapping is discussed in section 3.

3. Connectivity Verification Bootstrapping

   Bootstrapping is accomplished by sending an MPLS Echo Request message
   containing a Connectivity Verification Session object and a FEC stack
   which specifies the LSP for which connectivity verification is
   desired.  The next section describes the Connectivity Verification
   Session object.  Subsequent sections describe the procedures for the
   root and leaves.

3.1. Connectivity Verification Session Object

   The Connectivity Verification Session object is used to notify the
   receivers 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Detect Mult  |A|F|               MUST Be Zero                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Discriminator                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Min CV TX Interval                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Refresh Interval                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Response Jitter Interval                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Detect Mult

         Detection multiplier.  The Min_TX_Interval multiplied by this
         value, provides the Detection_Time for the receivers.

Swallow & Nadeau             Standards Track                    [Page 4]


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

      Administratively Down (A)

         This flag indicates that the connectivity verification session
         is administratively down.  This permits the session to be
         quieced without alarming.

      Forward Defect (F)

         This flag indicates a defect upstream of the LSP.  It MAY be set
         in order to suppress alarms downstream of the LSP.

      Discriminator

         A unique, nonzero discriminator value generated by the
         transmitting system, used to demultiplex multiple BFD sessions
         between the same pair of systems.

      Min TX Interval

         This is the minimum interval, in microseconds, that the source
         system will use when transmitting Connectivity Verification
         Probes.

      Refresh Interval

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

      Response Jitter Interval

         The interval over which MPLS Echo Reply messages are to be
         randomly delayed in milliseconds.

3.2. Bootstrap and Maintenance Procedures at the Root

   The root initiates bootstrapping by sending an MPLS Echo Request mes-
   sage containing a Connectivity Verification Session object and a FEC
   stack which specifies the LSP for which connectivity verification is
   desired.

   The Refresh Interval is set to a relatively long value.  The root
   MUST refresh the session within this interval.  The root MAY jitter
   refresh messages but the Refresh Interval serves as a hard upper
   bound on the jittering.  MPLS Echo Requests which refresh the CV Ses-
   sion SHOULD be sent on average at approximately one third of the
   Refresh Interval.

Swallow & Nadeau             Standards Track                    [Page 5]


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

   The Response Jitter Interval 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 dependent.  As
   such, the exact setting of this interval is beyond the scope of this
   document.

   Together the Min TX Interval, the Detection Multiplier determines the
   maximum amount of time it will take for a fault to be declared.
   Appropriate values should be chosen.  The suggested default value for
   the Detection Multiplier is 3.

   When any of the following conditions apply, the root should behave as
   if it were first bootstrapping the session.  That is it should seek
   Echo Responses from all receivers.  It this is not possible, for
   example, because the subject P2MP LSP needs to be removed quickly,
   then Detection_Multiple MPLS Echo Request messages SHOULD be sent
   prior to effecting the change.

       Changing the Discriminator
       Decreasing the Detection Multiplier
       Increasing the Minimum_Tx_Interval
       Increasing the Refresh_Interval
       Ceasing the transmission of CV Probe messages subsequent to
          signaling "Administratively Down"

3.2.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 Response 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.

3.2.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 3 times at a relatively short
   interval.

   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

Swallow & Nadeau             Standards Track                    [Page 6]


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

   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.3. Bootstrapping Proceedures at an Egress

   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 and FEC stack.  If not it creates state as specified in sec-
   tion 3.3.1 below.  If it does it updates that state as specified in
   section 3.3.2.

3.3.1. Creating Egress Connectivity Verification State

   State is created keyed on the source IP address and Discriminator
   value.  The lifetime for this state is set to expire in
   Refresh_Interval milliseconds.  The session is considered to have
   expired if not refreshed prior to the expiration of this timer.

   The Detection_Time is calculated equal to the value of Detection_Mul-
   tiplier times the Min_TX_Interval.  The Detection_Multiplier value is
   (roughly speaking, due to jitter) the number of packets that have to
   be missed in a row to declare the session to be down.

   A Detection_Timer is created, which upon expiration will invoke
   detection notification.  The timer is set to the Detection_Time.  If
   the Administratively Down flag is not set, the timer is started.

   If the Forward Defect Flag is set, an up call to any registered
   applications is made.

   An MPLS Echo Reply message is sent as normal, except that it is
   delayed by the Response_Jitter_Interval times a random number between
   zero and one.

3.3.2. Updating Egress Connectivity Verification State

   If an Connectivity Verification Session object is received which
   matches the Source_IP_Addr and FEC Stack of existing CV state but has
   a different Discriminator, new state is created as normal with two
   exceptions.  First the new state does not create a new timer; instead

Swallow & Nadeau             Standards Track                    [Page 7]


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

   the state points to the timer of the existing state.  Second, once an
   MPLS Connectivity Verification Probe has been received containing the
   new Discriminator, the old state MAY be removed.

   If either the Min_TX_Interval or Detection_Multiplier has changed,
   the Detection_Time is recalculated.

   If the Administratively_Down flag transitions from down to up, then
   the Detection_Timer is set to Detection_Time and stated.

   If the Administratively_Down flag transitions from up to down, then
   the Detection_Timer is stopped.

   If the Forward_Defect flag changes state, an up call to any regis-
   tered applications is made.

4. MPLS Connectivity Verification Probing

   A new LSP Ping message, the MPLS Connectivity Verification Probe, is
   defined for connection verification probing.  MPLS Connectivity Veri-
   fication Probes are sent by the root node of the tree.  Leaves listen
   for these messages and alarm in their absence.

4.1. MPLS Connectivity Verification Probe

   The definitions of the Version Number and Message Type fields are as
   in [LSP-PING].  The message type is 5 (provisional; to be assigned by
   IANA).  The Discriminator is the value that was advertised in the
   associated Connectivity Verification Session object.

   The message 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Version Number        |         MUST Be Zero          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message Type |                  MUST Be Zero                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Discriminator                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Swallow & Nadeau             Standards Track                    [Page 8]


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

4.2. Sending MPLS Connectivity Verification Probes

   The root forms an MPLS Connectivity Verification Probes formated as
   above with the Discriminator set to a value associated with the LSP
   to be probed.  The message encapsulated in UDP.  The source UDP port
   is chosen by the sender; the destination UDP port is set to <tba>.
   The source IP address is set to the address used in the MPLS Echo
   Request Message used to bootstrap this session.  The destination
   address is set to any address in the range 127.x.x.x.  The IP TTL is
   set to 1.  he packet is transmitted periodically on the LSP.  The
   packets MAY be jittered, but MUST be sent within Min_CV_TX_Interval
   microseconds of the previous message.

4.3. Receiving MPLS Connectivity Verification Probes

   Receivers listen for these messages based on the state received in
   the CV Session objects.  When a message arrives the receiver checks
   to see if it has state for the tuple <Source_IP_Addr, Discriminator>.
   If so it resets the associated CV_Detection_Timer to Detection_Time
   microseconds.  Note that during a change in Discriminators, more than
   one <Source_IP_Addr, Discriminator> may be pointing to a particular
   timer (with the Source_IP_Addr constant).  In this situation there
   are also multiple Detection_Intervals which could have differing val-
   ues.  The Detection_Timer MUST be updated with the value associated
   with the received Discriminator.

4.4. MPLS Connectivity Verification UDP Port

   MPLS Connectivity Verification Probes MUST be sent to port <to be
   assigned by IANA>.

5. Multicast LDP FEC Stack Sub-object

   The format of the Multicast LDP FEC Stack sub-object is shown below.
   The Sub-TLV type is <tba> (to be assigned by IANA).

Swallow & Nadeau             Standards Track                    [Page 9]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt          June 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Address Family         | Address Length| Root Node Addr|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Root Node Address (Cont.)                      |
   ~                           "                                   ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Opaque Length              |    Opaque Value ...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Address Family

      A two octet quantity containing a value from ADDRESS FAMILY
      NUMBERS in [3] that encodes the address family for the Root LSR
      Address.

   Address Length

      The length of the Root LSR Address in octets.

   Root Node Address

      A host address encoded according to the Address Family field.

   Opaque Length

       The length of the Opaque Value, in octets.

   Opaque Value

      An opaque value elements which uniquely identifies the P2MP LSP
      in the context of the Root Node.

   If the Address Family is IPv4, the Address Length MUST be 4; if the
   Address Family is IPv6, the Address Length MUST be 16.  No other
   Address Lengths are defined at present.

Swallow & Nadeau             Standards Track                   [Page 10]


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

6. Security Considerations

   TBD

7. IANA Considerations

   This document makes the following codepoint assignments (pending IANA
   action):

       Registry             Codepoint    Purpose

       UDP Port                tba       MPLS Verification Request

       LSP Ping Message Type    5        MPLS Connectivity Verification
                                           Probe

       LSP Ping Object Type    13        Connectivity Verification
                                           Parameters

       LSP Ping FEC Stack     tba        Multicast LDP FEC
           Sub-object Type

8. Acknowledgments

   The authors would like to thank Vanson Lim for his comments and sug-
   gestions.

9. References

9.1. Normative References

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

   [SELF-TST] Swallow, G. et al., "Label Switching Router Self-Test",
              <draft-ietf-mpls-lsr-self-test-07.txt>, June 2006.

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Swallow & Nadeau             Standards Track                   [Page 11]


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

   [MCSTPING] "Detecting Data Plane Failures in Point-to-Multipoint
              MPLS Traffic Engineering - Extensions to LSP Ping",
              <draft-ietf-mpls-p2mp-lsp-ping-01.txt>, April 2006.

9.2. Informative References

   [MPLS-BFD] Aggarwal, R., et al., "

10. Authors' Addresses

      George Swallow
      Cisco Systems, Inc.
      1414 Massachusetts Ave
      Boxborough, MA 01719

      Email:  [email-masked]

      Tom Nadeau
      Cisco Systems, Inc.
      1414 Massachusetts Ave
      Boxborough, MA 01719

      Email:  [email-masked]

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

   December 2006

Swallow & Nadeau             Standards Track                   [Page 12]


Internet Draft     draft-swallow-mpls-mcast-cv-00.txt          June 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
   [email-masked].

   Issues:

   Named Leaves Only

   To set up CV monitoring to a subset of leaves

   Error Suppression

   Is this useful.  A leaf with no ability won't recognize the flag.
   Can get around this with the do not reply setting.

   Sequence Numbers in probes

   Explicit withdrawal of a Discriminator

Swallow & Nadeau             Standards Track                   [Page 13]


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

      New Receivers Only (N)

         This flag indicates that only those receivers which are
         establishing new state based on the receipt of this message
         SHOULD respond.

   Refresh messages MAY be sent with the "New Receivers Only" flag set
   to suppress response messages from receivers that have previously
   responded.  This flag SHOULD only be set when no parameters have been
   altered.

   Error for same IP, Discriminator & different FEC - or just discard.

   F Flag in Probe. Control, or both?

Swallow & Nadeau             Standards Track                   [Page 14]


_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls