INTERNET DRAFT                                            Venu Hemige
                                                                Alcatel
  Internet Engineering Task Force                         Yetik Serbest
  Document:                                                         SBC
  draft-hemige-serbest-l2vpn-vpls-pim-snooping-                 Ray Qiu
  00.txt                                               Suresh Boddapati
                                                                Alcatel
  November 2005
  Category: Informational
  Expires: May 2006




                         PIM Snooping over VPLS

Status of this memo

  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/ietf/1id-abstracts.txt.

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

IPR Disclosure Acknowledgement

  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.

Abstract

  In Virtual Private LAN Service (VPLS), as also in IEEE Bridged
  Networks, the switches simply flood multicast traffic on all ports in
  the LAN by default. IGMP/MLD Snooping is commonly deployed to ensure
  multicast traffic is not forwarded on ports without IGMP/MLD receivers.
                                                              [Page 1]


^L
 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  The procedures and recommendations for IGMP/MLD Snooping are defined in
  [IGMP-SNOOP]. But when any protocol other than IGMP or MLD is used, the
  common practice is to simply flood multicast traffic to all ports.
  PIM-SM, PIM-SSM, PIM-BIDIR are widely deployed routing protocols. PIM
  Snooping procedures are important to restrict multicast traffic to
  only the routers interested in receiving such traffic.

  While most of the PIM Snooping procedures defined here also apply to
  IEEE Bridged Networks, VPLS demands certain special procedures due to
  the split-horizon rules that require the Provider Edge (PE) devices
  to co-operate. This document describes the procedures and
  recommendations for PIM-Snooping in VPLS to facilitate replication to
  only those ports behind which there are interested PIM routers and/or
  IGMP/MLD hosts.

  Conventions used in this document

  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.

Table of Contents

   1. Contributing Authors............................................3
   2. Introduction....................................................3
   2.1. Definitions...................................................4
   3. Overview of VPLS................................................4
   4. Multicast Traffic over VPLS.....................................5
   5. Constraining of IP Multicast in a VPLS..........................6
   5.1. General Rules for PIM Snooping in VPLS........................7
   5.2. PIM Snooping for VPLS.........................................7
   5.2.1. PIM Snooping State Summarization Macros.....................8
   5.2.2. Snooping PIM Packets.......................................11
   5.2.2.1. Join Suppression Issues..................................11
   5.2.2.2. Forwarding PIM Packets...................................11
   5.2.3. Discovering PIM Routers....................................11
   5.2.4. PIM-DM.....................................................12
   5.2.4.1. Building PIM-DM Snooping States..........................12
   5.2.4.1.1 PIM-DM Downstream Per-Port PIM(S,G,N) State Machine.....12
   5.2.4.2. Triggering ASSERT election in PIM-DM.....................13
   5.2.5. PIM-SM and PIM-SSM.........................................13
   5.2.5.1. Building PIM-SM Snooping States..........................13
   5.2.5.1.1 PIM-SM Downstream per-port PIM-SM (S,G,N)/(*,G,N) State
   Machine...........................................................14
   5.2.5.1.2 PIM-SM Downstream per-port PIM-SM (S,G,Rpt,N) State
   Machine...........................................................14
   5.2.5.2. Triggering ASSERT Election in PIM-SM.....................14
   5.2.6. Bidirectional-PIM (BIDIR-PIM)..............................17
   5.2.6.1. Building BIDIR-PIM Snooping States.......................17
   5.2.6.1.1 BIDIR-PIM Downstream per-port BIDIR-PIM (*,G,N) State
   Machine...........................................................18
                                                              [Page 2]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

   5.2.7. Multicast Source Directly Connected to the VPLS Instance...18
   5.2.7.1. PIM Join Suppression Issues..............................18
   5.3. Data Forwarding Rules........................................19
   6. IANA Considerations............................................19
   7. Security Considerations........................................19
   8. Normative References...........................................20
   9. Informative References.........................................20

1. Contributing Authors

  This document was the combined effort of several individuals.  The
  following are the authors, in alphabetical order, who contributed to
  this document:

         Suresh Boddapati
         Venu Hemige
         Sunil Khandekar
         Vach Kompella
         Marc Lasserre
         Rob Nath
         Ray Qiu
         Yetik Serbest
         Himanshu Shah

2. Introduction

  In Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices
  provide a logical interconnect such that Customer Edge (CE) devices
  belonging to a specific VPLS instance appear to be connected by a
  single LAN. Forwarding information base for particular VPLS instance
  is populated dynamically by source MAC address learning.  This is a
  straightforward solution to support unicast traffic, with reasonable
  flooding for unicast unknown traffic.  Since a VPLS provides LAN
  emulation for IEEE bridges as wells as for routers, the unicast and
  multicast traffic need to follow the same path for layer-2 protocols
  to work properly.  As such, multicast traffic is treated as broadcast
  traffic and is flooded to every site in the VPLS instance.

  VPLS solutions (i.e., [VPLS-LDP] and [VPLS-BGP]) perform replication
  for multicast traffic at the ingress PE devices.  When replicated at
  the ingress PE, multicast traffic wastes bandwidth when:
      1. Multicast traffic is sent to sites with no members,
      2. Pseudo wires to different sites go through a shared path, and
      3. Multicast traffic is forwarded along a shortest path tree as
         opposed to the minimum cost spanning tree.

  This document is addressing the first problem by IGMP/MLD and PIM
  snooping. Problems #2 and #3 are orthogonal to #1 and outside the
  scope of this document. The different methods to get traffic from a
  PE to other PEs and the pros and cons of each method are discussed in
  [RAHUL-VPLS-MCAST].

  Using VPLS in conjunction with IGMP/MLD and/or PIM snooping has the
  following advantages:
                                                              [Page 3]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

       - It improves VPLS to support IP multicast efficiently (not
          necessarily optimum, as there can still be bandwidth waste if
          traffic from a PE to other PE(s) is not forwarded along a
          minimum cost spanning tree.),
       - It prevents sending multicast traffic to sites with no
          members.

  Procedures for IGMP/MLD Snooping are specified in [IGMP-SNOOP]. This
  document describes the procedures for Protocol Independent Multicast
  (PIM) snooping over VPLS for efficient distribution of IP multicast
  traffic. It also describes the rules when both IGMP/MLD and PIM are
  active in a VPLS instance.

 2.1. Definitions

  The following definitions and abbreviations are used throughout this
  document:

       - A port is defined as either an attachment circuit (AC) or a
          Pseudo-Wire (PW).
       - When we say a PIM packet is received on a port, it means the
          packet is snooped ingressing on that port.
       - A router port associated with router R (Rport( R )) is
          defined as the port used to reach the router R.

  Abbreviations used in the document:

       - S: IP Address of the Multicast Source.
       - G: IP Address of the Multicast Group.
       - N: Upstream Neighbor field in a Join/Prune/Graft message.
       - Rport(X): Port on which neighbor X is learnt
       - UP: Rport(N)

3. Overview of VPLS

  In case of VPLS, the PE devices provide a logical interconnect such
  that CE devices belonging to a specific VPLS appear to be connected
  by a single LAN.  End-to-end VPLS consists of a bridge module and a
  LAN emulation module ([L2VPN-FR]).

  In a VPLS, a customer site receives Layer-2 service from the SP.  The
  PE is attached via an access connection to one or more CEs.  The PE
  performs forwarding of user data packets based on information in the
  Layer-2 header, that is, MAC destination address.  The CE sees a
  bridge.

  The details of VPLS reference model, which we summarize here, can be
  found in [L2VPN-FR].  In VPLS, the PE can be viewed as containing a
  Virtual Switching Instance (VSI) for each L2VPN that it serves.  A CE
  device attaches, possibly through an access network, to a bridge
  module of a PE.  Within the PE, the bridge module attaches, through
  an Emulated LAN Port to an Emulated LAN.  For each VPLS, there is an
                                                              [Page 4]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  Emulated LAN instance.  The Emulated LAN consists of VPLS Forwarder
  module (one per PE per VPLS service instance) connected by pseudo
  wires (PW), where the PWs may be traveling through Packet Switched
  Network (PSN) tunnels over a routed backbone.  VSI is a logical
  entity that contains a VPLS forwarder module and part of the bridge
  module relevant to the VPLS service instance [L2VPN-FR].  Hence, the
  VSI terminates PWs for interconnection with other VSIs and also
  terminates attachment circuits (ACs) for accommodating CEs.  A VSI
  includes the forwarding information base for a L2VPN [L2VPN-FR] which
  is the set of information regarding how to forward Layer-2 frames
  received over the AC from the CE to VSIs in other PEs supporting the
  same L2VPN service (and/or to other ACs), and contains information
  regarding how to forward Layer-2 frames received from PWs to ACs.
  Forwarding information bases can be populated dynamically (such as by
  source MAC address learning) or statically (e.g., by configuration).
  Each PE device is responsible for proper forwarding of the customer
  traffic to the appropriate destination(s) based on the forwarding
  information base of the corresponding VSI.

4. Multicast Traffic over VPLS

  In VPLS, if a PE receives a frame from an Attachment Circuit (AC)
  with no matching entry in the forwarding information base for that
  particular VPLS instance, it floods the frame to all other PEs (which
  are part of this VPLS instance) and to directly connected ACs (other
  than the one that the frame is received from).  The flooding of a
  frame occurs when:
       - The destination MAC address has not been learned,
       - The destination MAC address is a broadcast address,
       - The destination MAC address is a multicast address.

  Malicious attacks (e.g., receiving unknown frames constantly) aside,
  the first situation is handled by VPLS solutions as long as
  destination MAC address can be learned.  After that point on, the
  frames will not be flooded.  A PE is REQUIRED to have safeguards,
  such as unknown unicast limiting and MAC table limiting, against
  malicious unknown unicast attacks.

  There is no way around flooding broadcast frames.  To prevent runaway
  broadcast traffic from adversely affecting the VPLS service and the
  SP network, a PE is REQUIRED to have tools to rate limit the
  broadcast traffic as well.

  Similar to broadcast frames, multicast frames are flooded as well, as
  a PE cannot know where multicast members reside.  Rate limiting
  multicast traffic, while possible, should be should be done carefully
  since several network control protocols relies on multicast.  For one
  thing, layer-2 and layer-3 protocols utilize multicast for their
  operation.  For instance, Bridge Protocol Data Units (BPDUs) use an
  IEEE assigned all bridges multicast MAC address, and OSPF is
  multicast to all OSPF routers multicast MAC address.  If the rate-
  limiting of multicast traffic is not done properly, the customer
  network will experience instability and poor performance.  For the

                                                              [Page 5]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  other, it is not straightforward to determine the right rate limiting
  parameters for multicast.

  A VPLS solution MUST NOT affect the operation of customer layer-2
  protocols (e.g., BPDUs).  Additionally, a VPLS solution MUST NOT
  affect the operation of layer-3 protocols.

  In the following section, we describe procedures to constrain the
  flooding of IP multicast traffic in a VPLS.

5. Constraining of IP Multicast in a VPLS

  The objective of improving the efficiency of VPLS for multicast
  traffic that we are trying to optimize here has the following
  constraints:
       - The service is VPLS, i.e., a layer-2 VPN,
       - In VPLS, ingress replication is required,
       - There is no layer-3 adjacency (e.g., PIM) between a CE and a
          PE.

  Under these circumstances, the most obvious approach is
  implementation of IGMP/MLD and PIM snooping in VPLS.  Other multicast
  routing protocols such as DVMRP and MOSPF are outside the scope of
  this document.

  Another approach to constrain multicast traffic in a VPLS is to
  utilize point-multipoint LSPs (e.g., [PMP-RSVP-TE]).  In such case,
  one has to establish a point-multipoint LSP from a source PE (i.e.,
  the PE to which the source router is connected to) to all other PEs
  participating in the VPLS instance.  In this case, if nothing is
  done, all PEs will receive multicast traffic even if they do not have
  any members hanging off of them.  One can apply IGMP/MLD and PIM snooping,
  but this time IGMP/PIM snooping should be done in P routers as well.
  One can propose a dynamic way of establishing point-multipoint LSPs,
  for instance by mapping IGMP/PIM messages to RSVP-TE signaling.  One
  should consider the effect of such approach on the signaling load and
  on the delay between the time the join request received and the
  traffic is received (this is important for IPTV application for
  instance).  This approach is outside the scope of this document.

  Although, in some extremely controlled cases, such as a ring topology
  of PE routers with no P routers or a tree topology, the efficiency of
  the replication of IP multicast can be improved.  For instance, spoke
  PWs of a hierarchical VPLS can be daisy-chained together and some
  replication rules can be devised.  These cases are not expected to be
  common and will not be considered in this document.

  In the following sub-sections, we provide some guidelines for the
  implementation of PIM snooping in VPLS. Snooping techniques need to
  be employed on ACs at the downstream PEs. Snooping techniques can
  also be employed on PWs at the upstream PEs. This may work well for
  small to medium scale deployments. However, if there are a large
  number of VPLS instances with a large number of PEs per instances,
  then the amount of snooping required at the upstream PEs can
                                                              [Page 6]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  overwhelm the upstream PEs. In [VPLS-MCAST-LDP] and [VPLS-MCAST-BGP],
  procedures are defined to exchange multicast membership information
  between the PEs using LDP or BGP. Using a reliable mechanism like LDP
  or BGP allows the upstream PEs to eliminate the requirement to snoop
  on PWs. It also eliminates the need to refresh multicast states on
  the upstream PEs.

 5.1. General Rules for PIM Snooping in VPLS

  The following rules for the correct operation of IGMP/PIM snooping
  MUST be followed.

  Rule 1: IGMP and PIM messages forwarded by PEs MUST follow the split-
  horizon rule for mesh PWs as defined in [VPLS-LDP].

  Rule 2: IGMP/PIM snooping states in a PE MUST be per VPLS instance.

  Rule 3: Multicast traffic MUST be replicated per PW and AC basis,
  i.e., even if there are more than one PIM neighbor behind a PW/AC,
  only one replication MUST be sent to that PW/AC.


 5.2. PIM Snooping for VPLS

  IGMP/MLD snooping procedures described in [IGMP-SNOOP] provide efficient
  delivery of IP multicast traffic in a given VPLS service when end
  stations are connected to the VPLS.  However, when VPLS is offered as
  a WAN service it is likely that the CE devices are routers and would
  run PIM between them.  To provide efficient IP multicasting in such
  cases, it is necessary that the PE routers offering the VPLS service
  do PIM snooping.

  PIM is a multicast routing protocol, which runs exclusively between
  routers. PIM shares many of the common characteristics of a routing
  protocol, such as discovery messages (e.g., neighbor discovery using
  Hello messages), topology information (e.g., multicast tree), and
  error detection and notification (e.g., dead timer and designated
  router election).  On the other hand, PIM does not participate in any
  kind of exchange of databases, as it uses the unicast routing table
  to provide reverse path information for building multicast trees.
  There are a few variants of PIM.  In PIM-DM ([PIM-DM]), multicast
  data is pushed towards the members similar to broadcast mechanism.
  PIM-DM constructs a separate delivery tree for each multicast group.
  As opposed to PIM-DM, other PIM flavors (PIM-SM [PIM-SM], PIM-SSM
  [PIM-SSM], and BIDIR-PIM [BIDIR-PIM]) invoke a pull methodology
  instead of push technique.

  PIM routers periodically exchange Hello messages to discover and
  maintain stateful sessions with neighbors.  After neighbors are
  discovered, PIM routers can signal their intentions to join/prune
  specific multicast groups.  This is accomplished by having downstream
  routers send an explicit join message (for the sake of
  generalization, consider Graft messages for PIM-DM as join messages)
  to the upstream routers.  The join/prune message can be group
  specific (*,G) or group and source specific (S,G).
                                                              [Page 7]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005


  In PIM snooping, a PE snoops on the PIM message exchange between
  routers, and builds its multicast states.

  Based on the multicast states, it forwards IP multicast traffic
  accordingly to avoid unnecessary flooding.

  5.2.1. PIM Snooping State Summarization Macros

  The following sets are defined to help build the forwarding state on
  a PE. Some sets may apply only to a subset of the PIM Protocol
  variants as noted along with the definition of the sets.

  All_Pim_Neighbors =
  Set of all PIM neighbors in a VPLS instance.

  PIM_DR =
  The PIM Neighbor which is the elected PIM designated router in the
  VPLS instance.

  pim_joins(*,G,N) =
  {
      All ports P such that
          DownstreamJPState(*,G,N,P) is either in Join
          or Prune Pending state.
  }
  This set applies to PIM-SM and BIDIR-PIM.

  pim_joins(*,G) =
  This set is the union of all pim_joins(*,G,N) for each N in
  All_Pim_Neighbors . This set applies only to PIM-SM and BIDIR-PIM.

  pim_joins(S,G,N) =
  {
      All ports P such that
          DownstreamJPState(S,G,N,P) is either in Join
          or Prune Pending state.
  }
  This set applies only to PIM-SM and PIM-SSM.

  pim_joins(S,G) =
  This set is the union of all pim_joins(S,G,N) for each N in
  All_Pim_Neighbors. This set applies only to PIM-SM and PIM-SSM.

  pim_iifs(*,G) =
  {
      All Rport(N) for each N in All_Pim_Neighbors such that
          Pim_joins(*,G,N) is not empty.
  }

  pim_iifs(S,G) =
  {
      All Rport(N) for each N in All_Pim_Neighbors such that
          Pim_joins(S,G,N) is not empty.
  }
                                                              [Page 8]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005


  pim_prunes(S,G,N) =
  {
      All ports P such that
          DownstreamPState(S,G,N,P) is in Pruned state.
  }
  This set applies only to PIM-DM.

  pim_prunes(S,G) =
  This is the union of all pim_prunes(S,G,N) for each N in
  All_Pim_Neighbors. This set applies only to PIM-DM.

  pim_prunes(S,G,rpt,N) =
  {
      All ports P such that
          DownstreamJPState(S,G,rpt,N,P) is in Prune or
          PruneTmp state.
  }
  This set applies only to PIM-SM.

  pim_prunes(S,G,rpt) =
  This set is the union of all pim_prunes(S,G,rpt,N) for each N in
  All_Pim_Neighbors. This set applies only to PIM-SM.


  For PIM-DM,

   pim_oiflist(S,G) = All_Pim_Neighbors (-) pim_prunes(S,G)
                     (+) pim_iifs(S,G)

  For PIM-SM, and PIM-SSM,

   Pim_inherited_oiflist(S,G,rpt) = pim_joins(*,G) (-)
                                    pim_prunes(S,G,rpt) (+)
                                    pim_iifs(*,G)


   pim_oiflist(*,G) = pim_joins(*,G) (+) pim_iifs(*,G)

   pim_oiflist(S,G) = pim_inherited_oiflist(S,G,rpt) (+)
                        pim_joins(S,G) (+) pim_iifs(S,G)

  For PIM-SSM,

   pim_oiflist(S,G) = pim_joins(S,G) (+) pim_iifs(S,G)

  For PIM-BIDIR,

   Pim_oiflist(*,G) = DF(RP(G)) + pim_joins(*,G)

  Where DF(RP(G)) is the AC/PW towards the router that is the
  designated forwarder for RP(G).

  In the above, one should note that pim_iifs if included in pim_oifs.
  This is necessary for handling duplicate traffic issue (i.e.,
                                                              [Page 9]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  triggering Assert) explained in Section 5.2.5.2. It should also be
  noted that multicast traffic received from a port in pim_iifs will
  not be sent back to that port jus because it is also in pim_oiflist,
  because VPLS split-horozin rule will prevent that.

  Note that pim_oiflist(S,G)/pim_oiflist(*,G) are not the complete list
  of outgoing ports (oiflist). IGMP/MLD also contribute to this list.


  In addition to the above state summarization macros, we define the
  following IGMP/MLD state summarization macros which are important
  while considering the forwarding behavior when both IGMP/MLD and PIM
  snooping is active in a VPLS instance.

  local_include(*,G) =
  {
      All ports P such that
          IGMP/MLD module or other local membership mechanism has
          determined that local members on port P desire to receive
          traffic sent to group G.
  }

  local_include(S,G) =
  {
      All ports P such that
          IGMP/MLD module or other local membership mechanism has
          determined that local members on port P desire to receive
          traffic sent from source S to group G.
  }

  local_exclude(S,G) =
  {
      All ports P such that
          IGMP/MLD module or other local membership mechanism has
          determined that local members on port P desire to NOT
          receive traffic sent from source S to group G.
  }

  local_iif(*,G) =
  {
      if local_include(*,G) is non-empty
          RPort(PIM_DR)
  }
  This sets contains the port towards the PIM_DR in the VPLS instance
  if local_inlclude(*,G) is non-empty.

  local_iif(S,G) =
  {
      if (local_include(*,G) (-) local_exclude(S,G) (+)
          local_include(S,G)) is non-empty
      {
          RPort(PIM_DR)
      }
  }

                                                             [Page 10]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  In the following sub-sections, snooping mechanisms for each variety
  of PIM are specified.

5.2.2. Snooping PIM Packets

  A PIM-Snooping PE snoops on the following PIM packets to build its
  multicast states.

       - PIM Hellos
       - PIM Join/Prunes
       - PIM Graft
       - PIM State Refresh

  Note that the PIM packets are not modified by the PE, but are only
  snooped for the purposes of building multicast states.

5.2.2.1.  Join Suppression Issues

  Since PIM Snooping switches build state by snooping on PIM Join/Prune
  packets, one rule is that CE PIM routers MUST disable join-
  suppression in the VPLS instance. If Join-suppression is not
  disabled, then traffic may not ever flow to some receivers when PIM
  snooping is enabled in the VPLS instance.

5.2.2.2. Forwarding PIM Packets

  PIM Packets that are snooped MUST also be forwarded as is in the VPLS
  instance. As noted in the previous section, it is assumed that the CE
  routers do not suppress their PIM Joins when they see Joins from
  other routers.


5.2.3. Discovering PIM Routers

  A PIM Snooping PE MUST snoop on PIM Hellos received on ACs and PWs.
  PIM Hellos are used by the snooping switch to discover PIM routers
  and their characteristics.

  The PE includes an entry in the PIM Neighbor Database containing the
  following fields from the PIM Hello it snoops on:

         MAC Address of the Router sending the PIM Hello.
         IP Address and address family of the Router sending the PIM
          Hello.
         Port (AC / PW) on which the PIM Hello was received.
         Hello-Hold-Time.
         Bi-Dir Capable.
         Tracking Support.
         DR Priority

  Please refer to [PIM-SM] for the meaning of the various fields
  mentioned here.

                                                             [Page 11]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  The <MAC-Address, Port> corresponding to the Routers IP Address is
  used to determine where to forward subsequent PIM Joins destined to
  that IP Address.

  When a PIM Hello is received, the PE MUST reset the neighbor-expiry-
  timer to Hello-Hold-Time. If a PE does not receive a Hello message
  from a router within Hello-Hold-Time, the PE MUST remove that router
  from the PIM snooping state. If a PE receives a Hello message from a
  router with Hello-Hold-Time value set to zero, the PE MUST remove
  that router from the PIM snooping state immediately.

  From the PIM Neighbor Database, a PE MUST be able to use the
  procedures defined in [PIM-SM] to determine
           Designated Router in the VPLS instance.
           If Tracking Support is active in the VPLS instance.


5.2.4. PIM-DM

  The characteristics of PIM-DM is flood and prune behavior.  Shortest
  path trees are built as a multicast source starts transmitting.

  The procedures to discover PIM-DM routers are as explained in section
  5.2.3.


5.2.4.1. Building PIM-DM Snooping States

  PIM-DM Snooping states are built by snooping on the PIM-DM Join,
  Prune, Graft and State Refresh messages received on AC/PWs and State-
  Refresh Messages sent on AC/PWs. By snooping on these PIM-DM
  messages, a PE builds the following states per (S,G,N) where S is the
  address of the multicast source, G is the Group address and N is the
  upstream neighbor to which Prunes/Grafts are sent by downstream CEs:

  Per PIM (S,G,N):

      Per Port PIM (S,G,N) Prune State:
       - DownstreamPState(S,G,N,P): One of {"NoInfo" (NI), "Pruned"
          (P), "PrunePending" (PP)}
       - Prune Pending Timer (PPT)
       - Prune Timer (PT)
       - Upstream Port (UP) (valid if the PIM(S,G,N) Prune State is
          "Pruned").

  From the above states, we can derive the macros pim_prunes(S,G,N),
  pim_prunes(S,G) and pim_iifs(S,G) that are defined in section 5.2.1.

5.2.4.1.1    PIM-DM Downstream Per-Port PIM(S,G,N) State Machine

  The downstream per-port PIM(S,G,N) state machine is as defined in
  section 4.4.2 of [PIM-DM] with a few changes relevant to PIM
  Snooping. When reading section 4.4.2 of [PIM-DM] for the purposes of
                                                             [Page 12]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  PIM-Snooping please be aware that the downstream states are built per
  (S, G, N, Downstream-Port} in PIM-Snooping and not per {Downstream-
  Interface, S, G} as in a PIM-DM router. As noted in the previous
  section 5.2.4.1. , the states (DownstreamPState) and timers (PPT and
  PT) are per (S,G,N,P).

5.2.4.2. Triggering ASSERT election in PIM-DM

  Since PIM-DM is a flood-and-prune protocol, traffic is flooded to all
  routers unless explicitly pruned. Since PIM-DM routers do not prune
  on non-RPF interfaces, PEs should typically not receive Prunes on
  Rport(RPF-neighbor). So the asserting routers should typically be in
  pim_oiflist(S,G). In most cases, assert election should occur
  naturally without any special handling since data traffic will be
  forwarded to the asserting routers.

  However, there are some scenarios where a prune might be received on
  a port which is also an upstream port (UP). If we prune the port from
  pim_oiflist(S,G), then it would not be possible for the asserting
  routers to determine if traffic arrived on their downstream port.
  This can be fixed by adding pim_iifs(S,G) to pim_oiflist(S,G) so that
  data traffic flows to the UP ports.


  5.2.5. PIM-SM and PIM-SSM

  The key characteristic of PIM-SM and PIM-SSM is explicit join
  behavior.  In this model, the multicast traffic is only sent to
  locations that specifically request it.  The root node of a tree is
  the Rendezvous Point (RP) in case of a shared tree (PIM-SM only) or
  the first hop router that is directly connected to the multicast
  source in the case of a shortest path tree. All the procedures
  described in this section apply to both PIM-SM and PIM-SSM, except
  for the fact that there is no (*,G) state in PIM-SSM.

  We assume that the PEs have the capability to store (S,G) states for
  PIM-SM snooping and forward/replicate traffic accordingly. This is
  not mandatory.  An implementation, can fall back to (*,G) states, if
  its hardware cannot support it.  In such case, the efficiency of
  multicast forwarding will be less.

  The procedures to discover PIM-SM routers in a VPLS instance are as
  described in section 5.2.3.



5.2.5.1. Building PIM-SM Snooping States

  PIM-SM and PIM-SSM Snooping states are built by snooping on the PIM-
  SM Join/Prune messages received on AC/PWs. PIM-SM Join/Prune Messages
  received by a PE on a port MUST be flooded within the VPLS instance.
  The snooping procedures described here assume that the CE routers
  support Explicit Tracking and therefore Join Suppression is disabled.
  If Join Suppression is not disabled, snooping states may not be built
  correctly.
                                                             [Page 13]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005


  The downstream state is built per (S,G,N)/(*,G,N)) where S is the
  address of the multicast source, * represents the shared tree rooted
  at the RP, G is the Group address and N is the upstream neighbor to
  which Join/Prune Messages are sent by downstream CEs. For PIM-SSM,
  (*,G,N) states are not applicable. The downstream state consists of:

  Per PIM (S,G,N)/(*,G,N):

      Per Port PIM (S,G,N) Join/Prune State:
       - DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune
          Pending" (PP) }
       - Prune Pending Timer (PPT)
       - Join Prune Expiry Timer (ET)
       - Upstream Port (UP) (valid if the PIM(S,G,N) Join Prune State
          is "Join" or "Prune Pending").

  From the above states, we can derive the macros
  pim_joins(S,G,N)/(*,G,N), and pim_iifs(S,G) that are defined in
  section 5.2.1.

  A PE MAY ignore a Join/Prune message for an (S,G) not addressed to
  its own AC ONLY if it has no ACs in OifList(S,G). Note that
  no ACs in OifList(S,G) means the PE is neither a source nor a sink
  for the traffic. It cannot be a source since pim_iif(S,G) is also
  part of OifList(S,G). If it is a source, then it needs to know about
  other sources in order to trigger assert. If it is a sink, then it
  needs to ensure that there is only one source so it has to keep track
  of all sources to trigger assert. If it is neither, it has no need to
  create state.


5.2.5.1.1  PIM-SM Downstream per-port PIM-SM (S,G,N)/(*,G,N) State
achine

  To correctly build PIM-SM snooping states, a PE will have to snoop on
  Join/Prune messages. The per-port state machine for receiving
  (*,G)/(S,G) Join/Prune messages is as described in Sections 4.5.2 and
  4.5.3 of [PIM-SM] with the exception that the downstream state is per
  port per upstream neighbor for a given (S,G)/(*,G) as opposed to per
  interface.

5.2.5.1.2  PIM-SM Downstream per-port PIM-SM (S,G,Rpt,N) State Machine

  The per-port state machine for receiving (S,G,Rpt) Join Prune
  messages is as described in Section 4.5.4 of [PIM-SM] with the
  exception that the downstream state is per port per upstream neighbor
  as opposed to per interface.

5.2.5.2. Triggering ASSERT Election in PIM-SM

  In PIM-SM, there are scenarios where multiple routers could be
  forwarding the same multicast traffic on a LAN. When this happens,

                                                             [Page 14]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  using PIM Assert Election process by sending PIM Assert Messages,
  routers ensure that only the Assert Winner forwards traffic on the
  LAN. In a typical LAN, the Assert Election is a data driven event and
  happens only if a router sees traffic on the interface to which it
  should be forwarding the traffic. Therefore, in the case of VPLS, in
  order to trigger Assert Election and stop duplicate traffic, it is
  necessary that two routers that are forwarding duplicate traffic for
  an (S,G)/(*,G) see each others traffic.

  The set pim_iifs keeps track of all the possible Rports from which
  traffic could arrive for a given state. Note that VPLS does not have
  the layer 3 routing information available to the routers in order to
  determine if the upstream neighbor information in the Join/Prune
  Message is correct or not. Therefore, it has to keep track of all the
  upstream routers to which Joins have been sent for a given state.
  The set pim_iifs is constructed for a given (S,G)/(*,G) as follows:
  1) When a Join is received targeted to an Upstream Neighbor N,
  Rport(N) is added to the pim_iif set, if it is not already in the
  set.
  2) When a Prune is received targeted to an Upstream Neighbor N,
  Rport(N) is removed from the pim_iif set if there is no other
  upstream neighbor on this port to which a Join for the state was
  sent.

  The pim_iif set is also a part of the macro pim_oiflist (Section
  5.2.1). This ensures that data is forwarded on all Rports where
  upstream neighbors are present, which in turn facilitates the routers
  on those ports to detect duplicate traffic, trigger Assert Procedures
  and stop the duplicate traffic. Note that the VPLS forwarding rules
  still apply i.e. a packet received on a PW MUST NOT be forwarded back
  on another PW even if the PW is in the pim_oiflist.

  Triggering Assert in certain scenarios is important. There can be
  some scenarios where CE routers can receive duplicate multicast
  traffic.  Let us consider the scenario in Figure 1.



                                      +------+ AC3 +------+
                                      |  PE2 |-----| CE3  |
                                     /|      |     |      |
                                    / +------+     +------+
                                   /     |             |
                                  /      |             |
                                 /PW12   |             |
                                /        |          +-----+
                               /         |PW23      |  S  |
                              /          |          +-----+
                             /           |             |
                            /            |             |
                           /             |             |
    +------+     +------+ /           +------+     +------+
    | CE1  |     |  PE1 |/   PW13     |  PE3 |     | CE4  |
    |      |-----|      |-------------|      |-----|      |
    +------+ AC1 +------+             +------+ AC4 +------+
                                                             [Page 15]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

                     |
                     |AC2
                 +------+
                 | CE2  |
                 |      |
                 +------+


  Figure 1 An Example Scenario for Triggering Assert
  In the scenario depicted in Figure 3, both CE1 and CE2 has two ECMP
  routes to reach the source "S".  Hence, CE1 may pick R3 as its next
  hop ("Upstream Neighbor"), and CE2 may pick CE4 as its next hop.  As
  a result, both CE1 and CE2 will receive duplicate traffic for a
  moment, then Assert procedures will kick in and duplicate traffic
  will be resolved. Here is the sequence of events:

  1. CE1 is sending a (S,G) Join with N=CE3.
  2. pim_iifs(S,G)={PW12} on PE1. PE1 floods the join and if using LDP
  (as explained in [VPLS-MCAST-LDP]), sends the Join via LDP on PW12.
  pim_oiflist(S,G)={AC1, PW12} on PE1.
  3. pim_iifs(S,G)={AC3} and pim_oiflist(S,G)=(PW12, AC3} on PE2.

  The above is all that needs to occur in most cases where there is no
  assert.

  4. CE2 sends a (S,G) Join with N=CE4.
  5. pim_iifs(S,G)={PW12, PW13} on PE1. PE1 floods the join and if
  using LDP, sends a Join via LDP on {PW12, PW13}.
  Pim_oiflist(S,G)={AC1, AC2, PW12, PW13} on PE1.
  6. PE2 receives the Join. Pim_iifs(S,G)={AC3, PW23} on PE2.
  pim_oiflist(S,G)={PW12, AC3, PW23} on PE2.
  7. PE3 receives the Join too. Pim_iifs(S,G)={AC4} on PE3.
  pim_oiflist={PW13, AC4} on PE3.

  So even before multicast traffic starts flowing, the pim_oiflist(S,G)
  on the PEs are (i.e., the forwarding plane):

  PE1: {AC1, AC2, PW12, PW13}
  PE2: {PW12, AC3, PW23}
  PE3: {PW13, AC4}

  By building such a forwarding state when Joins are processed, there
  needs to be no additional action taken when data traffic is received.
  PE1 does not need to detect duplicate traffic. Traffic from PE2 will
  automatically flow to PE3. When the assert election is complete, if
  CE3 becomes the assert winner, then

  8. CE2 sends a (S,G) Prune with N=CE4 and a (S,G) Join with N=CE3.
  9. The JP message (both prune and join) is flooded (or sent to
  pim_iifs(S,G)={PW12, PW13} via LDP). As a result of the Prune,
  pim_iifs(S,G)={PW12} and pim_oiflist(S,G)={AC1,AC2,PW12} on PE1.
  10. PE2 receives the Prune directed to CE4. As a result
  pim_iifs(S,G)={AC3} and pim_oiflist(S,G)={PW12, AC3}.
  11. PE3 receives the Prune too. As a result, pim_iifs(S,G)={} and
  pim_oiflist(S,G)={}. So, PE3 purges state for that (S,G).
                                                             [Page 16]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005


  After assert election, the forwarding state should be:

  PE1: {AC1, PW12}
  PE2: {PW12, AC2}
  PE3: {}




  5.2.6. Bidirectional-PIM (BIDIR-PIM)

  BIDIR-PIM is a variation of PIM-SM.  The main differences between
  PIM-SM and Bidirectional-PIM are as follows:
       - There are no source-based trees, and source-specific
          multicast is not supported (i.e., no (S,G) states) in BIDIR-
          PIM.
       - Multicast traffic can flow up the shared tree in BIDIR-PIM.
       - To avoid forwarding loops, one router on each link is elected
          as the Designated Forwarder (DF) for each RP in BIDIR-PIM.

  The main advantage of BIDIR-PIM is that it scales well for many-to-
  many applications.  However, the lack of source-based trees means
  that multicast traffic is forced to remain on the shared tree.

  The procedures to discover PIM-SM routers in a VPLS instance are as
  described in section 5.2.3. For BIDIR-PIM to work properly, all
  routers within the domain must know the address of the RP.  There are
  three methods to discover the RPs: 1. Static configuration, 2,
  Snooping Auto-RP messages, and 3. Snooping PIMv2 Bootstrap messages.
  Auto-RP and Bootstrap messages are multicast and will be flooded in
  the VPLS instance.

  During RP discovery time, PIM routers elect DF per subnet for each
  RP.  The algorithm to elect the DF is as follows: all PIM neighbors
  in a subnet advertise their unicast route to elect the RP and the
  router with the best route is elected. All PEs MUST snoop the DF
  elections messages and determine the DF for each (*,G) and the port
  towards the DF (DF(RP)) MUST be added to the oiflist whose RP(G) is
  RP. The DF election state machine is described as in Section 3.5 of
  [BIDIR-PIM].

5.2.6.1. Building BIDIR-PIM Snooping States

  The BIDIR-PIM snooping for Join and Prune messages is similar to PIM-
  SM and the following (some of which are repetitions from PIM-SM
  section) applies. BIDIR-PIM Snooping states are built by snooping on
  the BIDIR-PIM Join/Prune messages received on AC/PWs. PIM-SM
  Join/Prune Messages received by a PE on a port MUST be flooded within
  the VPLS instance. The snooping procedures described here assume that
  the CE routers support Explicit Tracking and therefore Join
  Suppression is disabled. If Join Suppression is not disabled,
  snooping states may not be built correctly.

                                                             [Page 17]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  The downstream state is built per (*,G,N) where * represents the
  shared tree, G is the Group address and N is the upstream neighbor to
  which Join/Prune Messages are sent by downstream CEs. The downstream
  state consists of:

  Per PIM (*,G,N):

      Per Port PIM (*,G,N) Join/Prune State:
       - DownstreamJPState: One of { "NoInfo" (NI), "Join" (J), "Prune
          Pending" (PP) }
       - Prune Pending Timer (PPT)
       - Join Prune Expiry Timer (ET)
       - Upstream Port (UP) (valid if the PIM(*,G,N) Join Prune State
          is "Join" or "Prune Pending").

  From the above states, we can derive the macros pim_joins(*,G,N), and
  pim_iifs(*,G) that are defined in section 5.2.1.

5.2.6.1.1  BIDIR-PIM Downstream per-port BIDIR-PIM (*,G,N) State
achine

  To correctly build PIM-SM snooping states, a PE will have to snoop on
  Join/Prune messages. The per-port state machine for receiving (*,G)
  Join/Prune messages is as described in Sections 3.4.1 and 3.4.2 of
  [BIDIR-PIM] with the exception that the downstream state is per port
  per upstream neighbor for a given (*,G) as opposed to per interface.

  5.2.7. Multicast Source Directly Connected to the VPLS Instance

  If there is a source in the CE network that connects directly into
  the VPLS instance, then multicast traffic from that source MUST be
  sent to all PIM routers on the VPLS instance apart from the outgoing
  interface list for the corresponding snooping state.  If there is
  already (S,G)/(*,G) snooping state that is formed on any PE, this
  will not happen per the current forwarding rules and guidelines.  The
  (S,G)/(*,G) state may not send traffic towards all the routers.  So,
  in order to determine if traffic needs to be flooded to all routers,
  a PE must be able to determine if the traffic came from a host on
  that LAN.  There are three ways to address this problem:
       - The PE would have to do ARP snooping to determine if a source
          is directly connected.
       - Another option is to have configuration on all PEs to say
          there are CE sources that are directly connected to the VPLS
          instance and disallow snooping for the groups for which the
          source is going to send traffic. This way traffic from that
          source to those groups will always be flooded within the
          provider network.
       - A third option is to require that sources of CE multicast
          routers must appear behind a router.

5.2.7.1. PIM Join Suppression Issues

                                                             [Page 18]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  For VPLS Multicast to work, the C-routers MUST disable PIM Join
  suppression. However, it is our understanding that existing
  deployments from several vendors do not support the capability to
  disable PIM Join suppression. If that is so, then VPLS Multicast
  simply does not work if we multicast the C-Joins to all C-routers.
  Also, the provider has no control over the configuration on a C-
  router (to ensure that C-Join Suppression is disabled).

  If the downstream PE determines that PIM Join suppression is active
  in a VPLS instance, then it MUST unicast-forward the C-Joins towards
  the RPF-neighbor field in the C-Join. This allows the C-Join to not
  be seen by other C-routers. Since we recommend that it unicast-
  forward the C-Join/Prune packets, it is important to ensure that the
  PIM control packets are received in order at the upstream C-router.
  To achieve this, the same ordering restriction that apply to
  broadcast and unknown frames apply to PIM control packets.



 5.3. Data Forwarding Rules

  The final list of outgoing ports for a given (S,G) or (*,G) is
  computed by combining the IGMP/MLD and PIM state summarization macros.

  OifList(*,G) = local_include(*,G) (+) pim_oiflist(*,G) (+)
                 local_iif(*,G)

  Oiflist(S,G) = local_include(*,G) (-) local_exclude(S,G) (+)
                 local_include(S,G) (+) pim_oiflist(S,G) (+)
                 local_iif(S,G)

  The following rules MUST be followed when forwarding multicast
  traffic in a VPLS:

       - Traffic arriving on a port MUST NOT be forwarded back onto
          the same port.
       - Due to VPLS Split-Horizon rules, traffic ingressing on a PW
          MUST NOT be forwarded to any other PW.

  Additional Guidelines:

       - If there is no matching FIB entry, then the PE MAY either
          discard the packet or send it to All_Pim_Neighbors or to a
          configured set of ports. How this is determined is outside
          the scope of this document.

6. IANA Considerations

  This document does not require any IANA assignments or action.


7. Security Considerations

                                                             [Page 19]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

  Security considerations provided in VPLS solution documents (i.e.,
  [VPLS-LDP] and [VPLS-BGP) apply to this document as well.

8. Normative References

9. Informative References

   [VPLS-LDP]       Lasserre, M, et al. "Virtual Private LAN Services
                    over MPLS", work in progress
   [VPLSD-BGP]      Kompella, K, et al. "Virtual Private LAN Service",
                    work in progress
   [L2VPN-FR]       Andersson, L, et al. "L2VPN Framework", work in
                    progress
   [PMP-RSVP-TE]    Aggarwal, R, et al. "Extensions to RSVP-TE for
                    Point to Multipoint TE LSPs", work in progress
   [RFC1112]        Deering, S., "Host Extensions for IP Multicasting",
                    RFC 1112, August 1989.
   [RFC2236]        Fenner, W., "Internet Group Management Protocol,
                    Version 2", RFC 2236, November 1997.
   [RFC3376]        Cain, B., et al. "Internet Group Management
                    Protocol, Version 3", RFC 3376, October 2002.
   [IGMP-SNOOP]     Christensen, M., et al. "Considerations for IGMP
                    and MLD Snooping Switches", work in progress
   [PIM-DM]         Deering, S., et al. "Protocol Independent Multicast
                    Version 2 - Dense Mode Specification", RFC 3973,
                    January 2005.
   [PIM-SM]         Fenner, W, et al. "Protocol Independent Multicast-
                    Sparse Mode (PIM-SM): Protocol Specification
                    (Revised)", draft-ietf-pim-sm-v2-new-11.txt, April
                    2005.
   [PIM-SSM]        Holbrook, H., et al. "Source-Specific Multicast for
                    IP", work in progress
   [BIDIR-PIM]      Handley, M., et al. "Bi-directional Protocol
                    Independent Multicast (BIDIR-PIM)", work in
                    progress
   [VPLS-MCAST-LDP] Qui, R, Serbest, Y, et al, "Using LDP for VPLS
               Multicast", draft-qiu-serbest-vpls-mcast-ldp-00.txt,
               Work in progress
   [VPLS-MCAST-BGP] Aggarwal, R, et al, "Propagation of VPLS IP
                    Multicast Group Membership Information", draft-
                    raggarwa-l2vpn-vpls-mcast-ctrl-00.txt, Work in
                    progress
   [VPLS-MCAST-TREES] Aggarwal, R, et al. "Multicast in VPLS", draft-
               raggarwa-l2vpn-vpls-mcast-01.txt, Work in progress.


Authors' Addresses

  Venu Hemige
  Alcatel North America
  701 East Middlefield Rd.
  Mountain View, CA 94043
  Venu.hemige@alcatel.com
                                                             [Page 20]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005


  Yetik Serbest
  SBC Labs
  9505 Arboretum Blvd.
  Austin, TX 78759
  Yetik_serbest@labs.sbc.com

  Ray Qiu
  Alcatel North America
  701 East Middlefield Rd.
  Mountain View, CA 94043
  Ray.Qiu@alcatel.com

  Suresh Boddapati
  Alcatel North America
  701 East Middlefield Rd.
  Mountain View, CA 94043
  Suresh.boddapati@alcatel.com

  Rob Nath
  Riverstone Networks
  5200 Great America Parkway
  Santa Clara, CA 95054
  Rnath@riverstonenet.com

  Sunil Khandekar
  Alcatel North America
  701 East Middlefield Rd.
  Mountain View, CA 94043
  Sunil.khandekar@alcatel.com

  Vach Kompella
  Alcatel North America
  701 East Middlefield Rd.
  Mountain View, CA 94043
  Vach.kompella@alcatel.com

  Marc Lasserre
  Riverstone Networks
  Marc@riverstonenet.com

  Himanshu Shah
  Ciena
  hshah@ciena.com


                                                             [Page 21]


 draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt   Nov, 2005

Intellectual Property Statement

  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.

Full copyright statement

  Copyright (C) The Internet Society (2005).

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























                                                             [Page 22]