Network Working Group Internet Draft M. Napierala Document: draft-mnapierala-mvpn-rev-01.txt AT&T Expires: October 2007 April 2007 Multicast MPLS/BGP VPNs Revisited 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes inter-site signaling procedures in MPLS/BGP IP VPNs that are required for preserving multicast traffic patterns in MVPN customer networks. It specifies necessary information elements and their exchange process for correct MVPN operation. 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 [i]. Napierala Expires - October 2007 [Page 1] Multicast MPLS/BGP VPNs Revisited Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. MPLS/BGP MVPN Control Plane Principles......................3 4. Congruent Multicast and Unicast Routing.....................5 4.1 Bypassing Shared RP Trees in MVPN........................5 5. Preserving PIM-SM Traffic Patterns in MVPN Context..........6 6. VPN C-Source Discovery in PIM-SM............................7 6.1 C-Source and C-RP are Not Co-located.....................8 6.2 C-Source and C-RP are Co-located........................11 6.3 Handling Initial Packets Sent on C-Shared Tree..........13 7. Supporting C-Shared Trees..................................14 8. VPN C-Source Discovery in PIM-SSM..........................14 8.1 C-Receiver Pruning......................................15 8.2 C-Source Becomes Inactive...............................15 9. Comparison with other Source Discovery Techniques..........15 10. Support of Anycast C-RP....................................16 11. Support of C-Bidir Trees...................................16 12. Discovery of MP2MP Applications............................18 13. PE-to-PE Signaling in Multicast MPLS/BGP VPN...............19 13.1 Multicast Routing Exchange in MPLS/BGP VPN............19 13.2 Multicast Tunnel and Source Announcements.............21 14. IANA Considerations........................................21 15. Security Considerations....................................21 16. References.................................................21 17. Acknowledgments............................................22 18. Author's Addresses.........................................22 19. Intellectual Property Statement............................22 20. Copyright Notice...........................................23 1. Introduction Multicast VPN (cf.[ii]) extends MPLS/BGP VPN services (cf.[iii]) by enabling customers to run native IP multicast within their IP VPN’s. From VPN customer perspective there is no change in the multicast operational model. Multicast distribution trees are built is a service provider network to carry VPN multicast traffic. Those trees are essentially point-to-multipoint (P2MP) or multipoint-to- multipoint (MP2MP) tunnels that encapsulate IP VPN multicast packets for transport across SP network. Throughout this document whenever we refer to a VPN we mean MPLS/BGP IP VPN. The existing MVPN solution [iv] and new proposal [ii] cannot handle multiple parallel paths to MVPN customer RP or customer source. They do not allow for different downstream PE’s to choose different upstream RPF neighbors to C-RP or C-S. As a consequence, inter-PE C- multicast traffic can flow only along one C-tree and can never Napierala Expires – October 2007 [Page 2] Multicast MPLS/BGP VPNs Revisited simultaneously utilize multiple paths in redundant topology. Only one copy of every C-multicast packet is allowed to flow between PE’s in MVPN. The elimination of parallel paths for multicast traffic removes one of the main benefits of IP VPNs that different VRFs of the same MVPN might have different unicast routing policies and choose different paths to reach C-RP or C-S. It breaks Anycast RP procedure in MVPN by not allowing multiple C-RP’s to send traffic in parallel to their closest receiver PE’s. Allowing only a single inter-PE path for C-RP and C-S traffic is necessary in C-multicast signaling procedures as defined in [iv] and [ii], in order to assure that there is never duplicate multicast traffic sent to PE’s in MVPN. This is accomplished using either PIM Assert process in [iv] or a designated forwarder in [ii][vii]. In plain PIM, the former technique is used in PIM-on-LAN and the latter in PIM Bidir. These techniques are too restrictive and not necessary to achieve duplicate-free operation of MVPN’s. C-multicast signaling procedures based on these techniques do not preserve the expected multicast traffic patterns in MVPN customer network. In this document we propose new procedures for exchanging multicast routing in MPLS/BGP IP VPNs that allow for multicast traffic to traverse multiple inter-PE paths without duplicate packets at receiver PE’s, and to preserve unicast and multicast routing congruency in a VRF. We also define other required information that has to be exchanged for correct MVPN operation, in particular, active MVPN source, active MVPN group, and multicast tunnel announcements. A direct consequence of the proposed procedures is simplification of inter-PE multicast traffic patterns and inter-PE routing in MVPN, while preserving multicast traffic paths in MVPN customer network. 2. Terminology In this document we will refer to the MVPN customer multicast routes as "C-multicast routes". We will prefix MVPN customer multicast sources, groups, Rendezvous Points, and PIM routes with “C-“, as in: C-S, C-G, C-RP, (C-*, C-G), (C-S, C-G). We assume familiarity with PIM protocol [v] and the terminology used in [ii]. 3. MPLS/BGP MVPN Control Plane Principles There are several main principles that multicast MPLS/BGP IP VPN control plane should follow. This section described these principles. If the same VRF is used for unicast and multicast routing then multicast routing should follow unicast routing policy as defined by the VRF. This is expected behavior of IP MVPN. There are two necessary conditions to achieve multicast and unicast routing Napierala Expires – October 2007 [Page 3] Multicast MPLS/BGP VPNs Revisited congruency. The first condition is that PE joins a tunnel to receive source C-S traffic only after C-S has been discovered and it is known to this PE. The second necessary condition that to receive C-S or C-G traffic, downstream PE joins only those tunnels that were announced by its best next hop to C-S or C-RP. An upstream PE which is the RPF neighbor to C-S or C-RP should be unique per set of VRF’s with the same unicast routing policy towards the C-S or C-RP, respectively. RPF neighbor selection should not include not installed BGP routes because this might alter the expected traffic flows in MVPN. This is in contrast with [ii] where all VPN-IP routes, imported and not imported into a VRF, are used to determine the upstream RPF neighbor. This single forwarder election breaks the multicast and unicast routing congruency in a VRF. Support of multiple RPF neighbors for Anycast C-RP is also required. Support of Anycast RP that is consistent with its PIM SM definition is defined in section 10 of this document. Another necessary condition to achieve the correct multicast traffic flows in MVPN is that a tunnel for C-S traffic cannot be signaled or created only after the source sends traffic natively (i.e., not via C-RP) on (C-S, C-G) state. Signaling of tunnel information upon the source sending traffic natively on (C-S, C-G) is not sufficient since it might lead to a non-negligible amount of duplicate or unwanted traffic being sent to receivers. The MVPN implementation in SP’s infrastructure should be simplified as much as possible from the normal ASM procedures, while preserving the expected multicast traffic patterns in VPN customer network. The amount of customer multicast control messages carried across SP network should be minimized. Inter-PE C-multicast traffic should not be sent via shared tree (RPT's) before being switched to shortest path tree (SPT). The simplification or reduction of inter-site MVPN routing information should not require multicast protocol changes in the customer domain. There should be no shifts of multicast VPN traffic in the Service Provider network to assure stability of traffic patterns. Specifically, there should be no switching of traffic between shared trees and shortest path trees within SP network or between different tunnels in SP network. There should be an out-of-band mechanism that would allow constrained distribution of tunnel information, constrained distribution of information about active VPN sources, and constrained distribution of customer multicast control messages. Sending all multicast VPN control information out-of-band will allow for separating multicast control plane from its data plane. Napierala Expires – October 2007 [Page 4] Multicast MPLS/BGP VPNs Revisited 4. Congruent Multicast and Unicast Routing Current deployments [iv] as well as new proposal [ii] for MPLS/BGP Multicast VPN use LAN-based or LAN-like based RPF neighbor selection. To avoid duplicate traffic, they employ a Designated Router (DR) or Designated Forwarder election process that chooses a single forwarder (single upstream PE) for any C-S or C-G traffic. This single forwarder election is not based on unicast routing policy in a VRF but rather on the internal addressing used by SP network, i.e., among all candidate PE’s the PE with the highest IP address is chosen as the forwarder. Yet, it is customer expectation that multicast routing in a layer 3 VPN is congruent with unicast routing policy, if the same VRF instance is used for forwarding unicast and multicast traffic. The single forwarder election also breaks the expected behavior for Anycast C-RP where different RPF neighbors might be chosen to reach the C-RP. A consequence of the lack of routing congruency is that VPN hosts might receive duplicated or unwanted multicast traffic, or traffic that is forwarded by the wrong upstream router. We propose a solution to this problem whose main idea is that a PE joins a tunnel for C-S (or C-G) traffic only after C-S (or C-G) has been discovered to be active and that a PE joins only tunnels announced by its best next hop to C-S (or C-G). Hence, multicast traffic from a source C-S is never sent to a downstream PE over a tunnel that is not rooted at this PE’s best next hop towards C-S. An active source should be discovered in MVPN no later or negligibly later than it would in plain ASM multicast, so that the amount of traffic that is lost, duplicated, or misrouted is negligible. Different methods for source discovery exist. PE can itself discover the sources attached to it or it can learn it from other PE's in MVPN. Source discovery methods differ in how quickly they discover active sources and whether the discovery method requires exchanging of control information with VPN customer’s Rendezvous Points. The source discovery methods are defined in section 6 of this document. 4.1 Bypassing Shared RP Trees in MVPN In native IP Any-Source Multicast (ASM) mode the only purpose of shared trees is for multicast hosts to discover the sources of multicast traffic they are interested in. Once the source is discovered in ASM, last-hop routers usually immediately switch from shared tree to shortest path tree. However, it is not necessary to perform the RPT-to-SPT traffic switching between PE’s in MVPN. In MVPN context, the ASM source discovery process can be “intercepted” by PE’s in order to extract VPN source information. The interception of the ASM discovery process Napierala Expires – October 2007 [Page 5] Multicast MPLS/BGP VPNs Revisited should result in PE-to-PE traffic being sent only on SPT’s regardless of whether it was or it wasn’t switched to SPT’s in customer domain. This avoids unnecessary shifts of traffic in SP network and leads to simplification of PE-to-PE multicast routing. However, switching to C-source trees by PE’s should not alter the expected multicast traffic patterns in VPN customer network. In order to eliminate inter-site RPT-to-SPT switchover, PIM control procedures in MVPN context are modified. Those modifications are straightforward and do not require changes to PIM protocol in the customer domain. 5. Preserving PIM-SM Traffic Patterns in MVPN Context PIM-SM has the capability for last-hop routers (i.e. routers with directly connected receivers) to switch to the shortest-path tree and bypass the RP if the traffic rate is above a configured threshold called the “SPT-threshold”. SPT thresholds are configured to control when to switch to the shortest-path tree (SPT). The default value of the SPT-threshold is typically zero. This means that the default behavior for PIM-SM last-hop routers attached to active receivers is to immediately join the SPT to the source as soon as the first packet arrives via the (*,G) shared tree. By switching to SPT, the optimal path is used to deliver the multicast traffic. Depending on the location of the source in relation to the RP, this switch to the SPT can significantly reduce network latency. However, in networks with large numbers of senders, SPT’s can increase amount of state that must be kept in the routers. VPN customer might set SPT-threshold to a value higher than zero in order to switch to SPT’s only for sources that cross certain traffic rate. This is done in order to alleviate RP from carrying too much traffic while at the same time controlling the number of (S, G) states created in the network. If an SPT-threshold of “infinity” is specified for a group, the sources will not be switched to SPT and will always remain on the shared tree. Our goal is to bypass C-RPT to C-SPT traffic switching between PE’s while preserving the multicast traffic patterns in MPVN context, and, in particular, to conform to SPT thresholds set in customer network. There are two scenarios that need to be considered: (1) C-S and C-RP reside at different VPN sites, and (2) C-S and C-RP are co-located and reside at the same VPN site. We assume that whenever C-S and C-RP are located in different VPN sites the best path from C-RP to C-S is via SP network. Similarly, we assume that if C-S and C-RP are located in the same VPN site the best path from C-RP to C-S is outside of SP network. Napierala Expires – October 2007 [Page 6] Multicast MPLS/BGP VPNs Revisited In scenario (1) the (C-S, C-G) state is already created by a PIM Join issued by C-RP towards C-S and, hence, switching at receiver PE’s to SPT will not introduce new multicast states or change multicast traffic patterns within the site with C-S (or any other VPN site). In this scenario, immediate switching to SPT’s between PE’s is transparent to the customer network. As a consequence, PIM-SM C-trees can be by default automatically triggered as SPT’s by all egress PE’s with no inter-PE RPT-to-SPT switchover initiated by C-routers. Regardless of whether or not the traffic in customer’s network switched to SPT’s, PE-to-PE MVPN traffic is sent only on SPT’s. In scenario (2), the optimal path from C-S to C-RP at the C-S/C-RP site might not be along the optimal path from CE to C-RP. With such a topology, switching to SPT towards C-S will change the C-S traffic pattern at its site and will create new (C-S, C-G) state along the newly created path. If switching from RPT-to-SPT is based on non-zero SPT-threshold then a specific source C-S traffic might never be switched to SPT if C-S rate does not reach the configured threshold. Hence, under scenario (2), to preserve PIM SM traffic patterns in customer network, inter-PE C-multicast routing cannot be altered. When C-S and C-RP are co-located, C-shared tree and C-source tree overlap between PE’s. Hence, there is no inter-PE traffic switching from C-RPT to C-SPT required. All C-G traffic, i.e., traffic from any source C-S sending to C-G, is kept on the same inter-PE tunnel, regardless whether it is flowing on shared tree on source tree in customer network. NOTE: even when C-S and C-RP do not reside at the same VPN site, a better path between them could be engineered in customer network to be outside of the SP core. Handling such a topology will complicate inter-PE C-multicast routing and will require full C-RPT to C-SPT switching between PE’s. We consider such scenario unusual and treat it the same as the scenario when non-co-located C-S and C-RP communicate across SP network. That is we will unconditionally switch all C-source traffic to SPT’s at the PE’s. Sections, 6, 7, and 8 define active C-source and C-group discovery when C-multicast trees are built with PIM-SM and PIM-SSM. In general, in PIM-SM an active source or active group is discovered when a PE with a customer RP behind it receives the first (C-*, C-G) packet from source C-S. In PIM-SSM an active source is discovered when a PE with a customer source (C-S) behind it receives the first (C-S, C-G) join, either from directly connected CE or from another PE in MVPN. 6. VPN C-Source Discovery in PIM-SM A VPN source (C-S, C-G) and its C-RP could communicate either across the SP network or outside of the SP network. We use two VPN sources Napierala Expires – October 2007 [Page 7] Multicast MPLS/BGP VPNs Revisited to cover these two topologies: a source C-S1 of C-G located at the same site as its C-RP, and a source C-S2 of C-G located at a different site and, possibly, even different PE than the C-RP of C-G. Whenever we say that C-S and C-RP are located in different VPN sites we also mean that the best path from C-RP to C-S is via SP network. Whenever we say that C-S and C-RP are located in the same VPN site we also mean that the best path from C-RP to C-S is outside of SP network. Sections 6.1 and 6.2 define, respectively, these two scenarios. 6.1 C-Source and C-RP are Not Co-located A PE attached to C-RP, upon receiving (C-*, C-G) PIM Join from another PE, will follow the normal ASM procedures: it will add an interface that leads to the SP’s core network to (C-*, C-G) outgoing interface list (OIL) and it will send (C-*, C-G) Join towards the C- RP. In meantime, a VPN source C-S of C-G has sent to C-RP a PIM Register message with encapsulated multicast data it in. The C-RP extracts the multicast data packet from the Register message and sends it over the shared (C-*, C-G) tree. However, the PE attached to C-RP should not forward any (C-*, C-G) traffic on the interface leading to SP’s core network. This is a change from ASM procedure but it does not affect PIM procedures in VPN customer domain. PE attached to C-RP “snoops” for the 1st packet received on (C-*, C- G) and extract from it C-source address. This is no different from the last hop router extracting source address from the first packet it receives on shared tree in plain ASM. When PE attached to C-RP receives the 1st multicast packet from the source C-S over (C-*, C- G)-tree it announces the active source C-S to all PE’s in the MVPN. If C-S and C-RP are not co-located PE attached to C-RP sends (C-S, C- G, rpt) Prune towards C-RP to stop receiving C-S traffic over the C- shared tree. PE attached to C-RP does not forward (C-*, C-G) traffic on the interface leading to SP’s core network. Upon receiving active source C-S announcement message, a PE that is the next hop to source C-S will send a message containing the information about a tunnel to be used for (C-S, C-G) traffic. PE announces the same tunnel for all C-sources sending to the same group C-G. Optionally, PEs attached to C-S after receiving C-S announcement from PE attached to C-RP, also send C-S announcements to all PE’s in MVPN. When PE attached to C-RP receives the C-S announcement from PE attached to C-S it withdraws its own C-S announcement. This way PEs attached to C-S can later on withdraw their source announcements when C-S becomes inactive. This is a tradeoff between more messaging and a solution where only the PE that sent the source announcement can withdraw it. Napierala Expires – October 2007 [Page 8] Multicast MPLS/BGP VPNs Revisited The PE’s attached to receivers of C-G (also called egress PE’s), upon receiving the source announcement for (C-S, C-G), will convert (C-*, C-G) PIM Join/Prune messages received from locally attached CE’s to (C-S, C-G) PIM Join/Prune for only those active sources C-S that are not co-located with C-RP. Each such egress PE will send (C-S, C-G) Join to its best next-hop to the source C-S. If the tunnel announcement for (C-S, C-G) traffic was also received, egress PE will also “join” the correct tunnel, i.e., the tunnel for (C-S, C-G) announced by this best next hop to C-S. As we stated above, the PE attached to C-RP will not forward any (C-*, C-G) traffic on the interface leading to SP’s core network. This interface serves solely the purpose of keeping (C-*, C-G) OIL non-empty. If there is more than one best next-hop to C-S (i.e., there are multiple equal cost paths), the PE will choose as the next hop the PE with the highest IP address. PE might utilize multicast multipath load splitting algorithm if there are multiple C-Si behind the same PE’s. All PE’s have to use the same load splitting algorithm in order to choose the same upstream PE for the same C-Si. Upon receiving packets directly from source C-S, receivers might switch to SPT’s and send (C-S, C-G) Joins. When C-RP and C-S are attached to different sites, egress PE does not need to forward this new (C-S, C-G) Join towards C-S, since in this scenario egress PE’s have already switch to SPT when C-S was discovered. The C-source discovery method defined in this section blocks all (C- *, C-G) data traffic between PE’s in MVPN. Hence, it completely eliminates inter-site RPT to SPT multicast traffic switching. 6.1.1 Dually Connected C-Receivers There could be scenario where a dually homed VPN site with receiver(s) chooses a different next-hop PE depending on whether a shared (C-*, C-G) tree or source (C-S, C-G) tree is joined. This means that shared and source trees diverge at this site. The PE which is on the shared/C-RPT tree will receive (C-S, C-G, rtp) Prune message from its directly connected CE and it will prune the CE-PE interface for C-S traffic off C-shared tree. The PE on the C-RPT might also stop joining the tunnel for (C-S, C-G) if there are no other receivers for (C-*, C-G) or (C-S, C-G) attached to it. However, as we will explain in section 6.1.3 it is preferred for the PE not to prune itself off the C-S tunnel since dually connected receiver might switch back to shared tree (i.e., SPT-threshold is greater than zero). The PE on the C-RPT does not need to propagate (C-S, C-G, rtp) Prune (if C-RP is at a remote PE) since C-S has been already pruned from the C-shared tree. Napierala Expires – October 2007 [Page 9] Multicast MPLS/BGP VPNs Revisited The egress PE on C-SPT will create (C-S, C-G) state if it does not exist yet and will send (C-S, C-G) Join towards C-S. It will also join the tunnel for (C-S, C-G) if it was not joined yet. 6.1.2 C-Receiver Pruning An egress PE will send (C-*, C-G) Prune message towards C-RP when its OIL for (C-*, C-G) becomes empty. The C-RP could be locally attached to this PE or it can be attached to a different PE. The egress PE will also send (C-S, C-G) Prune messages for all sources C-S for which it triggered SPT’s. 6.1.3 C-Shared Tree Switchback If a site attached to an egress PE switches back from C-SPT to C-RPT because C-S traffic rate fell below the SPT-threshold, the PE attached to this site will receive (C-S, C-G) Prune message on the C- SPT. In general, if C-S and C-RP of C-G are not co-located then the egress PE will not send (C-S, C-G) Prune message to a PE attached to C-S. This is because in this scenario, inter-PE C-trees are always SPT’s. However, we have to distinguish a scenario with a dually connected receiver and with SPT and RPT diverging at its site (as described in section 6.1.1). In this scenario, the (C-S, C-G) state on the PE on C-RPT attached to this receiver has the “R” bit set to denote that this forwarding state is applicable to traffic flowing down the shared tree and not the source tree. The (C-S, C-G) state at the PE on C-SPT attached to the dually-connected receiver will not have the “R” bit set. Hence, in this dually connected receiver scenario, even if C-S and C-RP of C-G are not co-located but the egress PE receives (C-S, C-G) Prune message and its (C-S, C-G) state does not have the “R” bit set, this PE will send (C-S, C-G) Prune message up C-SPT. The PE on C-RPT will receive (C-*, C-G) Join from the dually homed receiver’s site to rejoin the shared tree. Since (C-*, C-G) Join will be sent without a (C-S, C-G, rpt) Prune this will cause the (C-S, C- G) Prune state along C-RPT on the egress PE to be deleted which will permit (C-S, C-G) traffic to begin flowing down the C-RPT again. If the egress PE kept joining/participating in the tunnel for C-S traffic then C-S traffic will immediately flow on this PE. 6.1.4 C-Source Becomes Inactive When VPN source C-S stops sending traffic, the state (C-S, C-G) expires on PE’s attached to C-S, according to the standard PIM SM procedure. Upon (C-S, C-G) state expiration all PE’s attached to C-S will send the active source withdrawal message for C-S. Upon Napierala Expires – October 2007 [Page 10] Multicast MPLS/BGP VPNs Revisited receiving active source C-S withdrawal message, PE’s attached to C- RP’s of C-G will stop sending (C-S, C-G, rtp) Prune messages towards the C-RP’s. PE’s attached to receivers of C-G, upon receiving active source C-S of C-G withdrawal message, will stop joining tunnels announced for (C-S,C-G) and remove C-S source and its tunnel information. The state (C-S, C-G) also expires on PE’s attached to receivers of C-G after C- S stops sending traffic, as according to the standard PIM procedure. 6.2 C-Source and C-RP are Co-located When C-RP and C-S are located at the same site, in order not to change traffic patterns at this site, the C-shared tree has to be preserved between PE’s. The reasons for preserving shared trees and SPT-threshold based switching are explained in section 6. A PE attached to C-RP, upon receiving (C-*, C-G) PIM Join from another PE, will follow the normal ASM procedures: it will add an interface that leads to the SP’s core network to (C-*, C-G) outgoing interface list and it will send (C-*, C-G) Join towards the C-RP. In meantime, a VPN C-source of C-G located at a site behind this PE has sent a PIM Register message to C-RP with encapsulated multicast data it in. The C-RP extracts the multicast data packet from the Register message and sends it over the shared (C-*, C-G) tree. Section 6.3 discusses different options for handling the initial C-S sent over C-RPT. When the PE attached to C-RP receives the 1st multicast packet from any source C-S over (C-*, C-G), it announces a tunnel for the “active” group C-G to all PE’s in the MVPN. An “active” multicast group is a group with at least one active source. This requires the PE attached to C-RP to “snoop” for the first packet received on (C-*, C-G). However, in contrast with section 6.1, the PE does not need to extract from the packet the source address. When C-RP and C-S are co-located active C-G group and its tunnel information are one and the same message. It is not necessary to send a separate active C-group and C-group tunnel announcement messages. The active C-group announcement should contain the tunnel information. The PE’s attached to receivers of C-G (i.e., egress PE’s), upon receiving the active C-G announcement will “join” the tunnel announced by the best next hop to C-RP for C-G. If there is more than one best next-hop to C-RP, the PE will choose as the next hop the PE with the highest IP address or PE may utilize multicast multipath load splitting algorithm when there are multiple C-RP’s behind the same PE’s. Napierala Expires – October 2007 [Page 11] Multicast MPLS/BGP VPNs Revisited All C-G traffic, i.e., traffic from any source C-S sending to C-G, is kept on the same inter-PE tunnel, regardless whether it is flowing on shared tree on source tree in customer network. An MVPN PE that does not have any interested receivers for C-G when it receives an active C-G tunnel announcement message, it will store this information so it can join the tunnel for late receivers. Upon receiving packets directly from source C-S, receivers might switch to SPT’s and sent (C-S, C-G) Joins. In case C-RP and C-S are at the same site, egress PE will send (C-S, C-G) Joins towards C-S since in this scenario egress PE’s do not automatically switch to SPT upon C-S discovery. 6.2.1 Dually Connected C-Receivers There could be scenario where a dually homed VPN site with receiver(s) chooses a different next-hop PE depending on whether a shared (C-*, C-G) tree or source (C-S, C-G) tree is joined. This means that shared and source trees diverge at this site. The PE which is on the C-RPT tree will receive (C-S, C-G, rtp) Prune message from its directly connected CE and it will prune the CE-PE interface for C-S traffic off C-shared tree. The PE on the C-RPT should propagate (C-S, C-G, rtp) Prune message if there are no other receivers of (C- *, C-G) or (C-S, C-G) attached to it. Otherwise that C-S traffic will unnecessarily flow to this PE. The PE on the C-RPT might also stop joining the tunnel for C-G if there are no other receivers for (C-*, C-G) or (C-S, C-G) attached to it. However, as we will explain in section 6.2.3 it might be better for the PE on C-RPT not to prune itself off the C-G tunnel since dually connected receiver might switch back to the shared tree (i.e., SPT-threshold is greater than zero). The egress PE on C-SPT will create (C-S, C-G) state, if it does not exist yet. The PE will add the dually-homed site interface to (C-S, C-G) state OIL. The OIL of (C-S, C-G) also includes all the interfaces in (C-*S, C-G) OIL, if the state (C-*, C-G) exists on this PE. This is a standard PIM procedure. The egress PE on C-SPT will send (C-S, C-G) Join towards C-S. It will also join the tunnel announced for C-G if it did not join this tunnel yet. 6.2.2 C-Group Becomes Inactive The state (C-*, C-G) will expire on a PE attached to receiver(s) of C-G after no more (C-*, C-G) Joins are received by this PE, which is according to the standard PIM SM procedure. Upon (C-*, C-G) state Napierala Expires – October 2007 [Page 12] Multicast MPLS/BGP VPNs Revisited expiration the egress PE will stop joining the tunnel announced for C-G. The state (C-*, C-G) will expire on a PE attached to C-RP after no more (C-*, C-G) Joins are received by this PE, which is according to the standard PIM SM procedure. Upon (C-*, C-G) state expiration all PE’s attached to C-RP will send the tunnel withdrawal message for C- G. PE’s attached to receivers of C-G, upon receiving C-G tunnel withdrawal message, will remove the tunnel information. 6.2.3 C-Shared Tree Switchback If a site attached to an egress PE switches back from C-SPT to C-RPT because C-S traffic rate fell below the SPT-threshold, the PE attached to this site will receive (C-S, C-G) Prune message on the C- SPT. If C-S and C-RP of C-G are co-located then egress PE will send (C-S, C-G) Prune message up C-SPT. This is because in this scenario, we have to preserve inter-PE C-shared trees. The PE on C-RPT will receive (C-*, C-G) Join from the dually homed receiver’s site to rejoin the shared tree. Since (C-*, C-G) Join will be sent without a (C-S, C-G, rpt) Prune this will cause the (C-S, C- G) Prune state along C-RPT on the egress PE to be deleted which will permit (C-S, C-G) traffic to begin flowing down the C-RPT again. If the egress PE kept joining/participating in the tunnel for C-S traffic then C-S traffic will immediately flow on this PE. 6.3 Handling Initial Packets Sent on C-Shared Tree According to the C-source discovery method described in section 6 the initial multicast packets send over C-shared tree are dropped by PE attached to C-RP until a tunnel to be used for active C-S or active C-G is build. In this section we consider three different options for handling the initial packets sent over C-RP trees: (1) C-multicast traffic is dropped until S-PMSI tunnel is built (2) C-multicast traffic is dropped until UI-PMSI tunnel rooted at the PE attached to C-S is built (3) C-multicast traffic is not dropped but sent on MI-PMSI tunnel built during MVPN discovery With option (2), UI-PMSI tunnels have to be announced during MVPN discovery. This allows the PEs that received active source announcements to immediately join/build the UI-PMSI tunnels, without waiting for S-PMSI tunnel announcement. As a result the amount of initial traffic that is dropped is decreased. Since UI-PMSI and S- MPSI are rooted at the same ingress PE, switching from one to the Napierala Expires – October 2007 [Page 13] Multicast MPLS/BGP VPNs Revisited other does not cause traffic shift in the SP network. While on UI- PMSI tunnels, (C-S, C-G) traffic might be temporarily sent to PEs without interested receivers of (C-S, C-G). Option (3) assumes that MI-PMSI tunnels are built during MVPN discovery. This option applies only when C-RP and C-C are co-located. When C-RP and C-S are not co-located the C-S traffic is pruned off the shared tree after the 1st packet is received over C-RPT by PE attached to C-RP. When S-PMSI tunnel announcement for active C-G is received by egress PE, this PE joins the tunnel announced for C-G. The ingress PE attached to C-S will switch sending C-S traffic over MI-PMSI to S-PMSI. The C-S traffic will shift between these two different tunnels in SP network. Another drawback of option (3) is that the initial (C-*, C-G) packets even if delivered to the egress PE’s could be duplicates, received from wrong sources, or received not by the egress PE’s best next hop to C-RP. This could happen if different VRF’s of the same MVPN have different unicast routing policies. Since the initial traffic even if sent could be meaningless to receivers, there is no advantage in using MI-PMSI tunnel for C-traffic. Hence, the preferred option for handling the initial traffic is option (1) or option (2). Note: if PIM-on-LAN procedure is used for C-multicast routing the Assert process will force the same single forwarder for entire MVPN. Hence, with PIM-on-LAN the initial C-RPT traffic cannot be sent over MI-PMSI unless the Assert process is disabled in MVPN context. 7. Supporting C-Shared Trees Multicast VPN might never switch traffic to SPT’s for certain multicast C-groups if SPT-threshold of “infinity” is specified for those groups. The procedures defined in section 6.2 of this document preserve C-shared trees in case C-RP and C-S reside at the same VPN site. This is done in order to preserve the multicast states and traffic patterns in MVPN customer network. According to procedures in section 6.1, inter-PE traffic is automatically switched to source trees for those C-sources that are not co-located with their corresponding C-RP’s. However, under this scenario it is transparent to customer network whether multicast traffic is sent on shared or source trees across SP network. In other words, from customer network perspective multicast traffic is still on shared trees. 8. VPN C-Source Discovery in PIM-SSM With PIM-SSM an active C-source is discovered when a PE attached to C-source receives the first (C-S, C-G) Join, either from directly connected CE or from another PE in MVPN. Napierala Expires – October 2007 [Page 14] Multicast MPLS/BGP VPNs Revisited When a PE with a C-S located at its site receives the 1st (C-S, C-G) Join from another PE or from a locally attached CE, this PE will announce the tunnel to be used for (C-S, C-G) traffic to all other PE’s in the MVPN. In PIM SSM the source discovery and tunnel announcement is one and the same message. An egress PE with receiver(s) of (C-S, C-G) will “join” the tunnel announced for (C-S, C-G) only if the PE that sent this announcement is the best next hop to the source C-S on this egress PE. If there is more than one best next-hop to C-S, the PE will choose as the next hop the PE with the highest IP address or PE may utilize multicast multipath load splitting algorithm. 8.1 C-Receiver Pruning An egress PE will send (C-S, C-G) Prune message towards C-S when its OIL for (C-S, C-G) becomes empty. The C-S could be locally attached to this PE or it can be attached to a different PE. 8.2 C-Source Becomes Inactive The state (C-S, C-G) will expire on a PE attached to receiver(s) of (C-S, C-G) after no more (C-S, C-G) Joins are received by this PE, which is according to the standard PIM SSM procedure. Upon (C-S, C-G) state expiration the PE attached to the receivers will stop joining the tunnel announced for (C-S, C-G). The state (C-S, C-G) will expire on a PE attached to C-S after no more(C-S, C-G) Joins are received by the PE, which is according to the standard PIM SSM procedure. Upon (C-S, C-G) state expiration on a PE attached to C-S, this PE will send the tunnel withdrawal message for (C-S, C-G). PE’s attached to receivers of (C-S, C-G, upon receiving (C-S, C-G) tunnel withdrawal message, will remove the tunnel information. 9. Comparison with other Source Discovery Techniques The active multicast source discovery mechanisms described in section 6 do not introduce any requirements or restrictions on the MVPN service offering. Described techniques work with any multicast topology and with any RP protocol in customer domain. There are other source discovery methods possible. However, they either require changes in multicast procedures in customer network or they introduce specific requirements in how Multicast VPN service is offered. For example, PE could participate in PIM source discovery techniques in the customer domain. This requires one or more (for Napierala Expires – October 2007 [Page 15] Multicast MPLS/BGP VPNs Revisited redundancy) PE’s to act as customer RP’s or MSDP peers to customer RP. This technique completely eliminates inter-site PIM messages associated with shared trees and with RPT-to-SPT switching. However, it lays specific requirements on MVPN service offering and on the multicast design in the customer network. It either requires that MVPN customer is willing to outsource the RP functionality to the service provider (SP) or that customer RP establishes the MSDP peering with PE. Outsourcing the RP to service provider might not be desirable to neither, the customer or the SP. Also, it might not be feasible for the customer to run MSDP and for SP to support MSDP in MVPN context with every customer. Also, the RP assignment gets complicated if customer is using dynamic RP protocol (Auto-RP or BSR). Because of these reasons this is not a valid source discovery option. 10.Support of Anycast C-RP The existing MVPN solution [iv] and new proposal [ii] choose a single forwarder for C-RP or C-S traffic across entire MVPN. This breaks the expected Anycast C-RP behavior where different PE’s could choose different PIM neighbors as the next-hops to C-RP. Support of multiple RPF neighbors for Anycast C-RP is required. If there are multiple next-hops to static C-RP installed by BGP in VRF, the closest PE, based on SP’s network IGP cost, should be chosen as a next hop and only as a tie breaker the PE with the highest IP address. This should be a default behavior for static C-RPs. IGP cost-based next-hop selection provides PIM-like support of Anycast C- RP’s, i.e., C-receivers join the closest Anycast C-RP across SP network. Since a PE cannot distinguish multiple next hops to C-RP due to different Anycast C-RPs or due to static/Anycast C-RP being dually homed with equal-cost, closest distance-based next hop selection may trigger more tunnels in SP network. An option in supporting Anycast C-RP is to always use the highest IP address as a tie breaker for RPF neighbor selection and leave it to MVPN unicast routing policies to reach different Anycast-RP’s. This allows MVPN customer to define its own Anycast C-RP selection, based on other criterion than the closest distance. Hence, there should be support for turning off per MVPN the default, IGP cost-based, Anycast C-RP selection. 11.Support of C-Bidir Trees Napierala Expires – October 2007 [Page 16] Multicast MPLS/BGP VPNs Revisited Some multicast applications use many-to-many model where each participant is receiver as well as sender. Using PIM SM for such applications results in increased memory and protocol overhead. Bi-directional PIM eliminates both Register message encapsulation and source-specific states by allowing packets to be natively forwarded from a source to the RP using shared tree state only. This ensures that only (*,G) entries will appear in multicast forwarding tables and that the path taken by packets flowing from the source and/or receiver to the RP and vice versa will be the same. Membership to a Bidir group is signaled via explicit (*, G) join messages. Traffic from sources is unconditionally sent up the shared tree toward the RP and passed down the tree toward the receivers on each branch of the tree. This is in contrast with PIM SM where traffic flows are unidirectional. PIM Bidir chooses single Designated Forwarder (DF) for upstream packets (away from the source) on every network segment and point-to- point link. The DF procedure selects one router as the DF for every RP of bidirectional groups. DF is responsible for forwarding multicast packets upstream to RP as well as sending (*,G) Join/Prune messages towards RP. DF election procedure eliminates parallel downstream paths from any RP. To avoid loops, customized routing in downstream routers does not affect the choice of DF. This is in contrast with PIM SM procedures where there could be multiple parallel paths to RP and downstream routers might choose different upstream RPF neighbors to reach the RP. In MVPN context DF for Bidir C-RP is a PE attached to the C-RP with the tie breaker being the PE with the highest IP address. Since there can be only one DF per Bidir C-RP, MVPN has to assure that all VRF’s participating in multicast groups served by the C-RP have the same routing information. This is in contrast with PIM Sparse Mode where different VRF’s could choose different parallel paths to the same C- RP. There are two ways to assure this: (1) all VRFs of the same VPN have to have the same unicast routing policy. The best next hop to C-RP is chosen as a DF for C-RP’s bidirectional groups. The tie breaker is the highest IP address. (2) a group of VRF’s with the same unicast routing policy uses unique (across MVPN) C-RP(s) with unique (across MVPN) bidirectional groups. To assure that there is always only one forwarder for a Bidir C-RP in MVPN, all unicast VPN routes on a PE, imported and non-imported into VRF, should be considered when choosing the Designated Forwarder. This applies to both cases, (1) and (2), above. The OIL of a (*, G) entry for Bidir group G includes all the interfaces on which (*, G) Joins were received. If a router is located on a sender-only branch, it will also create (*, G) state but the OIL will not include any interfaces. Traffic in a Bidir Napierala Expires – October 2007 [Page 17] Multicast MPLS/BGP VPNs Revisited group is always forwarded to the RP of that group. If no receivers are along the way to the RP, the traffic will be dropped off only at the RP. Traffic will be forwarded to the RP even if there are no receivers at all. Since initially there are no inter-PE tunnels on which to send C- source traffic up the shared tree, (C-*, C-G) state is first created on PE, being the DF for C-RP, by a (C-*, C-G) Join from a locally connected or remote C-receiver. Once (C-*, C-G) state is created a DF-PE announces a tunnel for C-G traffic to all PE’s in MVPN. A PE in MVPN that does not have (C-*, C-G) state when it receives a C-G tunnel announcement message, it will store this information so it can join the tunnel for late receivers or/and sources. The state (C-*, C-G) will expire on a DF-PE after no more (C-*, C-G) Joins are received by this PE and no more C-sources are sending, which is according to the standard PIM Bidir procedure. Upon (C-*, C- G) state expiration DF-PE will send the tunnel withdrawal message for C-G. PE’s attached to participants of C-G, upon receiving C-G tunnel withdrawal message, will remove the tunnel information. For scalability, C-Bidir traffic should use MP2MP tunnels in SP network, build with PIM Bidir or with MP2MP LSP’s. 12.Discovery of MP2MP Applications Bidir groups in MVPN customer domain should be transported over Bidir or MP2MP trees in SP network. However, MVPN customer might use PIM-SM in its network to support many-to-many applications. It is desirable for SP network scalability that such applications are supported by Bidir or MP2MP trees in SP core. This section describes a procedure for discovering MP2MP applications in MVPN. Section 6.1 of this document describes C-source discovery in PIM-SM C-multicast groups. When PE’s discover that there are more than “N” sources sending to the same multicast group C-G, the PE’s should build (or switch to) one MP2MP tree rather than using multiple P2MP trees. The value of “N” dictates when a group is considered to carry MP2MP application. If the number of sources per group is lower than “N” this indicates few-to-many application and if it is higher than “N” then the application is considered to be multipoint-to- multipoint. When a PE in an MVPN learns about “N” or more C-sources sending to the same multicast group C-G, this PE will join/build a branch towards a MP2MP tree for C-G. If there exists already at least one P2MP tree rooted at this PE then this PE will switch the traffic from the existing P2MP tree(s) to the newly built MP2MP tree. If there Napierala Expires – October 2007 [Page 18] Multicast MPLS/BGP VPNs Revisited were no P2MP trees for C-G rooted at this PE or with this PE as the leaf of such trees, then this PE will join/build a branch towards a MP2MP tree for C-G and will send any traffic for C-G it receives from locally connected CE’s over this MP2MP tree. The details on announcing and switching to MP2MP tunnels will be provided in a future revision. 13.PE-to-PE Signaling in Multicast MPLS/BGP VPN The key functionality provided by multicast PE-PE signaling in MPLS/BGP VPN architecture consists of the following: - exchanging of VPN multicast routing information - signaling of active sources in a VPN - signaling of tunnel information to be used for multicast VPN traffic across the SP network. In this section we discuss MVPN PE-to-PE signaling protocol options and the differences between them. 13.1 Multicast Routing Exchange in MPLS/BGP VPN The following protocols could be used for exchanging MPLS/BGP VPN multicast routing among PE’s: PIM [iv], Multicast LDP [vi], and BGP [vii]. In this section we discuss each of these protocols. 13.1.1 PIM PIM procedures are well understood and well deployed. The existing MVPN implementation based on [iv] uses PIM-on-LAN procedures that force a designated PE for C-S or C-G traffic. According to the procedures described in this document, there is never duplicate multicast VPN data traffic received at the egress PE’s and multicast routing follows unicast routing policy in VRF. As a result, PIM Assert mechanism is not only no longer needed in MVPN but it should be removed from MVPN. Since PIM is a refresh based/soft-state protocol, PIM Join suppression and Prune override provide important optimizations in multicast VPN routing. However, they do not allow tracking PE’s with interested receivers, which is needed for tunnel aggregation in SP network. Hence, these mechanisms should not be used in MVPN. Yet, PIM-on-LAN procedures have to scale on PE routers to support large number of MVPN’s spanning large number of PE’s. Reliable PIM implementation (e.g., PIM-over-TCP, PIM with Join/Prune Acknowledgment) is needed for scaling PIM-based MVPN’s. 13.1.2BGP Napierala Expires – October 2007 [Page 19] Multicast MPLS/BGP VPNs Revisited BGP is a well known, TCP-based protocol already used for unicast routing in IP VPN’s. When BGP is used as multicast routing protocol PIM state machine changes are required to interact with BGP. The existing proposal to carry multicast routes in BGP, defined in [vii], does not address the RP discovery protocols like BSR and Auto-RP. Multicast BGP encoding in [vii] is still based on a single forwarder mechanism similar to DR-election in PIM-on-LAN procedure and, hence, does not support multiple inter-PE paths to C-RP or C-S. In general, BGP cannot fully re-create PIM, especially PIM-on-LAN, procedures for resolving duplicate traffic because they depend on the data plane. However, as we defined in this document, PE-to-PE signaling in MVPN can be simplified to the point that no duplicates are ever sent to egress PE’s, and, hence, a full translation of PIM in BGP is not required. In fact, inter-PE C-multicast routing defined in this document could be implemented in BGP. With unicast IP VPN’s, the main purpose of route reflectors is to scale BGP sessions on PE’s. With multicast VPN’s, route reflectors also provide another function which is the aggregation of multicast routes. With this functionality route reflectors protect PE’s from multicast route churn and volume by shifting this burden on themselves. This advantage of route reflectors is diminished with receiver tracking which is required for multicast tunnel aggregation in SP network. With PE-receiver tracking, a PE being a root of an SP tree needs to know every PE that is a receiver on that tree. Whether this information is a part of C-multicast route or it is sent in a separate route type as Leaf Auto-discovery route in [ii][vii], ultimately all PIM Join and Prune messages from a downstream PE has to be known to upstream PE. Each such route could be send directly to the upstream PE (if it could be sent reliably) rather than via a route reflector. Tunnel aggregation is crucial for scaling MVPN technology in SP network. Hence, PE-receiver tracking is a necessary feature in MVPN. Multicast route change frequency is different from unicast routing. Unicast route updates are the result of routing node configuration changes or failures. A unicast route exists regardless of whether there is a currently active application using this route. Multicast updates (PIM Joins/Prunes) are the result of applications joining or leaving a group (of course, not every join or leave results in an update at CE-PE and PE-PE). It is hard to characterize exactly what rate of PIM Join/Prune messages MPLS/BGP VPN may generate and its impact on BGP protocol. 13.1.3MLDP Napierala Expires – October 2007 [Page 20] Multicast MPLS/BGP VPNs Revisited In multicast LDP (MLDP) (cf. [vi]), as in PIM, trees are built receiver driven which allows it to scale well with dynamic multicast group membership and large receiver populations. In contrast to PIM, MLDP control messaging uses TCP and, hence, it is reliable and provides flow control. MLDP can support P2MP trees and MP2MP trees. The first are comparable to PIM SSM trees, the second to PIM Bidir trees. Supporting trees analogous to PIM Sparse Mode poses a difficulty in MLDP. PIM-SM is a combination between two types of trees, the (*,G) tree and the (S,G) tree. To avoid duplicates, packets received via the (*,G) tree on a router that has (S,G) tree must be denied. This is complex in the MPLS network because packets are forwarded using labels and there is no multicast state in the core. To solve this problem an out-of-band-signaling can be used to track (*,G) Join/Prune and (S,G,rpt) Prune messages. Since MLDP already requires out-of-band tracking of shared trees to support PIM- SM, inter-PE multicast signaling defined in this document could all be carried out-of-band. Out-of-band signaling is also required for MLDP tunnel aggregation. Hence, MLDP is in fact a data tunneling technology for MVPN. 13.2Multicast Tunnel and Source Announcements Source and Tunnel Announcement messages should use reliable delivery mechanism. When BGP is used as such delivery mechanism, source announcement has been already defined in [vii] as Source Active Auto- discovery route. The tunnel announcements are defined in [vii] only for (C-S, C-G) streams using S-PMSI auto-discovery route. According to procedures defined in this document we need a tunnel announcement also for active C-groups. This will added in the next version of the document. 14.IANA Considerations To be supplied. 15.Security Considerations To be supplied. 16.References [i] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Napierala Expires – October 2007 [Page 21] Multicast MPLS/BGP VPNs Revisited [ii] E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast. Work in progress. [iii] E. Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [iv] E. Rosen, Y. Cai, I. Wijnands, "Multicast in MPLS/BGP IP VPNs", draft-rosen-vpn-mcast. [v] B. Fenner et. al., "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [vi] I. Minei, I. Wijnands, et. al., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp. Work in progress. [vii] R. Aggarwal, et. Al., “BGP Encodings for Multicast in MPLS/BGP IP VPN”, draft-raggarwa-l3vpn-2547bis-mcast-bgp. Work in progress. 17.Acknowledgments The author thanks Yakov Rekhter, Bill Fenner, Toerless Eckert, and Lee Breslau for their comments and insights. 18.Author's Addresses Maria Napierala AT&T 200 Laurel Avenue, Middletown, NJ 07748 Email: mnapierala@att.com 19. 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 Napierala Expires – October 2007 [Page 22] Multicast MPLS/BGP VPNs Revisited 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 ietfipr@ietf.org. 20. Copyright Notice Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Napierala Expires – October 2007 [Page 23]