Internet Engineering Task Force INTERNET-DRAFT Gargi Nalawade/Cisco draft-nalawade-l3vpn-mcast-signaling-bgp-00.txt Nidhi Bhaskar/Cisco Pranav Mehta/Cisco September 2005 Expires: March 2006 Multicast PE to PE Signaling Using BGP Status of this Document 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. This document is an Internet-Draft and is in full conformance with all provisions of RFC 3978/3979 . 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 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 a "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract Multicast PE to PE Signaling is a key component of the L3MVPN architecture defined in MVPN [1]. This draft considers the option of using BGP with extensions for Multicast VPNs and describes the tradeoffs involved in using BGP. Nalawade Bhaskar Mehta [Page 1] ^L INTERNET-DRAFT Expires: March 2006 September 2005 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions. . . . . . . . . . . . . . . . . . . . . 4 2. BGP extensions for Multicast PE-PE Signaling. . . . . . 5 2.1. Import/Export Route-Targets for MVPNs. . . . . . . . 5 2.2. BGP extensions for carrying PIM Join/Prune binding . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. BGP Operation for PIM Join/Prune. . . . . . . . . 7 2.2.2. BGP PE-PE LSP or Tunnel binding . . . . . . . . . 8 2.2.3. Filtering for Join/Prune binding signaling. . . . 9 2.3. BGP extensions for RP-Mapping distribution . . . . . 9 2.4. BGP Capabilities . . . . . . . . . . . . . . . . . . 10 2.5. Security Considerations. . . . . . . . . . . . . . . 11 3. Tradeoffs . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Whats good about BGP . . . . . . . . . . . . . . . . 11 3.2. Whats not. . . . . . . . . . . . . . . . . . . . . . 11 4. Acknowledgements. . . . . . . . . . . . . . . . . . . . 13 5. Normative References. . . . . . . . . . . . . . . . . . 14 6. Informational References. . . . . . . . . . . . . . . . 14 7. Authors' Addresses. . . . . . . . . . . . . . . . . . . 14 8. Full Copyright Statement. . . . . . . . . . . . . . . . 16 Nalawade Bhaskar Mehta [Page 2] ^L INTERNET-DRAFT Expires: March 2006 September 2005 1. Introduction The Multicast architecture for L3VPN can be broken into the following fairly independent pieces of functionality: o The Customer Side Tree building protocol. This is the protocol which is used to construct the multicast tree in the customer's network. The well known protocol for this today is PIM. o The Core Tree building protocol. This is the protocol used to construct a tree in the core. Some examples of protocols used for this are PIM, MLDP, RSVP-TE with P2MP extensions. o A Mapping/Aggregation component. This is the component which specifies how to map a given multicast customer stream into a core tree. And stores aggregation policies. o A Multicast PE-PE Signaling component. Which signals VPN multicast routing information and also provides a tunnel binding if needed. The tunnel is used to transit the VPN multicast streams across the core. At a high level the operation for L3MVPN can be described as follows: o A PIM Join is received by a Downstream PE. Which uses the usual RPF lookup rules to figure out what Upstream PE it would like to receive traffic from. o The Downstream PE uses the PE-PE signaling protocol to inform the Upstream PE of its interest in the multicast stream. The Upstream PE propogates the Join further into the customer network. o The Upstream PE also uses its mapping/aggregation rules to determine on which tree in the core it would like to transmit the multicast stream.These mapping/aggregation rules could be either configured or discovered through some protocol. o The Upstream PE then uses the PE-PE signaling protocol to inform the Downstream PE of the Tunnel binding. o The Tunnel encapsulation information itself could be discovered/configured between the Upstream and Downstream PEs through various different available mechanisms. o The Downstream PE then uses the Tunnel Binding to join the appropriate tree in the core and receives the multicast stream. Nalawade Bhaskar Mehta Section 1. [Page 3] ^L INTERNET-DRAFT Expires: March 2006 September 2005 In this document we discuss the Multicast PE-PE Signaling protocol. What options are available for implementing such a protocol and the tradeoffs involved. For a detailed discussion of the L3MVPN architecture and the requirements for a Multicast PE-PE Signaling protocol, please refer to the MVPN [1] draft. Key functionality provided by Multicast PE-PE Signaling in the L3MVPN architecture is: o Transport VPN Multicast Routing information. o Transport a Tunnel Binding for the tree in the core. The protocol considered in this draft for implementing these is BGP. Also, note, the nature of the L3VPN architecture for multicast requires changes to the PIM protocol state machines as described in PIM-SM [7] and Bidir PIM [8] These changes are necessary regardless of what protocol BGP or PIM is used for PE Signaling. And are outside the scope of this document. 1.1. Definitions P Router A Provider Router which connects only to routers belonging to the same network & lies in the core of the network. PE Router A Provider Edge Router, which has some interfaces connected to the core or P routers and other interfaces that are connected to customer routers or other core networks. It lies on the edge of the provider's network. Upstream PE Router A Provider Edge Router, which has advertised reachability via itself for the Source or RP. The Upstream PE is also referred to as "Head-end", "Ingress PE". Downstream PE Router A Provider Edge Router, which has receivers behind it which wish to join an (S/*, G). The Downstream PE is also referred to as the "Tail-end" or "Egress PE". Nalawade Bhaskar Mehta Section 1.1. [Page 4] ^L INTERNET-DRAFT Expires: March 2006 September 2005 2. BGP extensions for Multicast PE-PE Signaling BGP runs over TCP which is a reliable transport. It also has the mechanisms for filtering via policy and flooding information through an ISP's network. It also has the necessary mechanisms for building, maintaining and routing VPN networks. In case of Multicast VPNs if BGP were used for PE-PE Signalling, it is possible to leverage some of the existing BGP mechanisms such as RT-based import/export, RT-based filtering reliable route-propagation to all BGP nodes and reduction of updates and sessions via Route-reflectors. For MVPNs, the following extensions would be needed in BGP. High Level extensions to BGP : o For carrying multicast J/P binding. o For carrying Tunnel binding. o For carrying Group to RP mapping. o Appropriate filtering mechanisms Apart from the above, new Route-Targets would need to be defined for this Multicast Overlay SAFI. 2.1. Import/Export Route-Targets for MVPNs A new set of import/export Route-Targets would need to be defined for Multicast VPNs. The current set of Route-Targets define the relationships between unicast VRFs. In case of extranets, the 2 VRFs have overlapping Route-Targets. These same relationships cannot be used for Multicast VPNs. For Multicast VPNs, each VPN has to have a unique set of import and export Route-Targets. If on one PE, there are 2 VRFs which belong to the same VPN, then they would need to have a unique set of Route-Targets and they can import from and export to the other VRF by configuring those in their import or export lists. It is these import and export lists for MVPNs which would be used when importing the PIM Join/Prune information or the RP-mapping information into the appropriate VRF.. Nalawade Bhaskar Mehta Section 2.1. [Page 5] ^L INTERNET-DRAFT Expires: March 2006 September 2005 2.2. BGP extensions for carrying PIM Join/Prune binding A new BGP SAFI called the Multicast Overlay SAFI is proposed for the purpose. The NLRI of this SAFI will have the encoding as follows : 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Route-Distinguisher | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream PE | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream PE (optional) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner-Label (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where, RD is an 8 octet Route-Distinguisher that uniquely identifies the Multicast Overlay SAFI Prefix Source-PE : is the address of the Source or the Head-end PE Flags : is a 2 octet field which identifies characteristics of the Join/Prune or binding represented in the NLRI o The Leftmost bit indicates whether the NLRI contains the Receiving PE's address or an Inner Label. If the bit is 0, it indicates that the NLRI contains the Receiving PE's address. If it is set to '1' then it indicates that the NLRI contains an Inner Label. Nalawade Bhaskar Mehta Section 2.2. [Page 6] ^L INTERNET-DRAFT Expires: March 2006 September 2005 o If the 2nd leftmost bit is set it indicates that the PIM Join/Prune is for a (*, G) In this case the Source field contains a value of 0xffff and is not relevant. o If the 3rd leftmost bit is set, it indicates that this is an SGR Prune o If the 4th leftmost bit is set, it indicates that this is the RP-bit The other bits are reserved. The flag field is part of the NLRI and each unique combination of the flag bits makes it a unique NLRI. S : is the address of the Source for which a PIM Join/Prune is to be sent G : is the Group address for which the PIM Join/Prune is to be sent Receiving-PE : is the address of the Receiving or the Tail-end PE Inner-Label : contains the Inner Label that may identify a given Multicast stream or VPN. This is an optional field and is not considered part of the BGP prefix. 2.2.1. BGP Operation for PIM Join/Prune When a Receiving PE receives a PIM Join for an (S, G), PIM checks the RPF information for the Source S and finds that it has been advertised by PE1. It then requests BGP to send a Join/Prune for that (S, G). In response BGP creates a local entry for the prefix in the LocRIB of the BGP Multicast Overlay SAFI {RD: PE1, S, G, Flags, Receiving-PE}. BGP will figure out the VRF from which the Source S had been imported. It will then attach the export Route-Target configured for this SAFI and VRF, and attach it with the prefix advertisement to its peers. This update could be implicitly filtered by other PE based on PE1's address. For easier filtering, PE1's address could be put into a BGP attribute. Upon Receiving this update, BGP would import it into the appropriate VRF's BGP Multicast Overlay SAFI LocRIB based on matching the RTs carried in the BGP update with its import list. It would then install this prefix into the PIM database. If PIM finds that there is no label allocated corresponding to the particular multicast stream, it will request BGP for binding for the (S/*/G). In response BGP may inject a prefix in the BGP Multicast Overlay SAFI LocRIB table for the VRF of the form {RD:PE1, S, G, Flags, Inner-Label}. BGP will attach the export Route-Targets for the VRF in the extended communities attribute and then advertise it to all the BGP peers. It will also attach a Tunnel Identifier and an indication on where to get obtain the Tunnel Nalawade Bhaskar Mehta Section 2.2.1. [Page 7] ^L INTERNET-DRAFT Expires: March 2006 September 2005 Encapsulation information from, in a Connector attribute with the BGP update. [3] If MLDP LSPs are to be used for Label-switching Multicast traffic through the core, the Connector attribute will carry the Tree- Identifier used by MLDP for the LSP, and indicate that this is to be used by MLDP which sets up the Multicast Tree in the core. If some other Tunneling mechanism is used, then the Connector attribute will carry a Tunnel Identifier and Tunnel-end-point address and indicate who is giving the binding. (Eg it could be IGP based RSVP-TE Tunnel discovery [5] or a BGP Tunnel SAFI that gives the binding). [4] Upon receiving the BGP update carrying the Inner-Label, the BGP on the Receiving PE would import it into the appropriate VRF's BGP Multicast Overlay SAFI LocRIB by matching the RTs in the update with the import-lists for Multicast VPNs for the VRFs. Once the BGP prefix gets imported into the appropriate VRF, it would then install this prefix into the PIM database. PIM receives the Tunnel Identifier and/or the Inner Label. It can obtain the Tunnel encapsulation information from the indication the Connector attribute. [3] 2.2.2. BGP PE-PE LSP or Tunnel binding The Tunnel encapsulation information could be discovered via BGP using MLDP (for Label based Multicast Trees), IGP-TE (for RSVP-TE tunnels) or the BGP IPv4/6 Tunnel SAFI (for generic Tunnels such as IPSec or L2TPv3). These Tunnels will be identified by an Identifier. Let us call this a Tunnel Identifier. The Receiving PE router will use this Tunnel-endpoint Identifier to bind the Multicast Overlay SAFI prefix with the appropriate Tunnel. The BGP Multicast Overlay SAFI will receive the Tunnel- endpoint Identifier and address in a Connector attribute [3] from the Source PE Router. If the Tunnel encapsulation is received via MLDP in the form of Outer Labels corresponding to the P-MP LSP, the Tunnel or Multicast Tree Identifier will be advertised through the Connector attribute with the Multicast Overlay SAFI. If the Tunnel encapsulation is received via IGP based RSVP/TE Tunnel discovery, the Tunnel Identifier for the RSVP/TE Tunnel will be carried in the Connector attribute with the Multicast Overlay SAFI. If only the Tunnel endpoint identifier and address needs to be signaled with the Multicast Overlay SAFI, then they would be carried in the Connector attribute. The advantage of using an out of band mechanism for acquiring Tunnel encapsulation information is that the Tunnel information could be pre- established and does not need to be advertised over & over again with Nalawade Bhaskar Mehta Section 2.2.2. [Page 8] ^L INTERNET-DRAFT Expires: March 2006 September 2005 each Multicast Overlay advertisement. There would be a big advantage in doing this esp if the Tunnels used have a large encapsulation data or the Tunnels could change. For example in the case of VPNv4-unicast that uses Multipoint-to-point L2TPv3 tunnels or IPSec Tunnels in lieu of LDP in the core; L2TPv3 (which has at least 6 to 14 octets) and IPSec (which has at least 5 to maybe even 255 octets or more of tunnel attribute length). It would also save a lot of time in formatting of BGP updates for the Multicast Overlay SAFI. It also keeps the Tunnel encapsulation signaling/discovery mechanism independent of the Multicast Overlay advertisements. 2.2.3. Filtering for Join/Prune binding signaling If the BGP update carrying the information for the PIM Join/Prune needs to be filtered so that it only reaches the Upstream PE, then this could be done by carrying the Upstream PE's address in an attribute and filtering on that. Else existing RT-filtering mechanisms could be leveraged so that the update is only sent to those PEs that participate in that MVPN. In the first case a new attribute or a special extended community could be used. For filtering based on RTs, the existing mechanisms of Extended-community ORF [2] or RT-constraint [6] could be extended for the Multicast Overlay SAFI and leveraged. If the BGP update carrying the Tunnel and/or Label binding information needs to be filtered so that it only recahes the Downstream PEs who participate in the MVPN then again the existing mechanisms of Extended- community ORF [2] or RT-constraint [6] could be extended for the Multicast Overlay SAFI and leveraged. If a further granularity of filtering so that this update reaches only the Downstream PEs which have Received a PIM Join for that Multicast Stream, then this can be done on the Downstream PEs when they receive the update. In such a case, if a new Downstream PE wants to join an existing multicast stream, then it would advertise the prefix {RD:Upstream PE, S, G, Flags, Receiving PE} to its iBGP peer/RR. When the RR receives this, it would advertise it to the Upstream PE and also have to trigger an update for the {RD:Upstream PE, S, G, Flags, Inner- Label} back to the Downstream PE. 2.3. BGP extensions for RP-Mapping distribution If PIM Join/Prune Binding is signaled using BGP, then there is a need for distributing the RP-Mapping information using BGP as well. This information is maintained per-MVPN and needs to be distributed to all Nalawade Bhaskar Mehta Section 2.3. [Page 9] ^L INTERNET-DRAFT Expires: March 2006 September 2005 the PEs participating in the given MVPN. This can be distributed using a new SAFI called the BGP Multicast RP- Mapping SAFI. The NLRI for this SAFI would be : {RD, RP-address, Group address Length, Group address} 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Route-Distinguisher | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP-address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group address Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where, RD is an 8 octet Route-Distinguisher that uniquely identifies the Multicast Overlay SAFI Prefix RP address : is the address of the RP Group address length : is the length of the Group address Group address : is the Group address part of the mapping information The PEs receiving this update would import this prefix into the appropriate VRF using the Route-Targets in the update. BGP would install the prefix to the underlying Multicast layer. Note that this could be combined with the Multicast Overlay SAFI by using the Flags bits. However the semantics of the 2 SAFIs is different and therefore are best kept separate. 2.4. BGP Capabilities A BGP Speaker that receives the MP_EXT Capability for the Multicast Nalawade Bhaskar Mehta Section 2.4. [Page 10] ^L INTERNET-DRAFT Expires: March 2006 September 2005 Overlay SAFI, MAY advertise the Multicast Overlay SAFI prefixes to that peer. A BGP Speaker that receives the MP_EXT Capability for the Multicast RP- Mapping SAFI, MAY advertise the Multicast RP-Mapping SAFI prefixes to that peer. 2.5. Security Considerations These extensions to BGP do not change the underlying security issues. 3. Tradeoffs 3.1. Whats good about BGP o Tooling - its deployed/scales and well understood in L3VPN space. This is a major plus point. BGP has already addressed the problems of scaling, security and policy in the L3VPN space. o TCP based, hard state, flow-control available for multicast routes. o 1-to-many communication via TCP exists and scales using RRs. o Inter-AS support well defined. Policies in place for unicast. 3.2. Whats not o Need analysis on whether BGP is a good fit for transporting multicast tree building states. o Unicast updates are the result of routing node failure/updates/configuration changes. Multicast updates (Joins/Prunes) are the result of applications joining/leaving a group. Of course, each application join or leave does not result in an update at the CE/PE. It is not clear whether multicast updates have the same characteristics in terms of frequency as unicast. And it is hard to characterize exactly what rate of Join/Prune messages a customer VPN may generate. Taking an example... o 100 PE core, each PE with 100 VPNs. Nalawade Bhaskar Mehta Section 3.2. [Page 11] ^L INTERNET-DRAFT Expires: March 2006 September 2005 If we have one upate per minute in each VPN on each PE then 100 BGP updates/minute which the PE needs to send out. In addition, it potentialy has to deal with 100 updates also being sent to it. So BGP deals with 200 updates/minute for multicast. Increase that by order of magnitude to 1000vrfs/1000 PEs, each PE deals with 2000 updates/minute. RR has to deal with 1000*2000 updates/minute. In general, it is difficult to characterize and control J/P behavior for multicast. Rate/frequency etc. Not clear how to protect unicast BGP L3VPN infrastructure. Also, what is the impact on multicast service (latency) to vpn customer if BGP uses route dampening for multicast. o RR Consideration. RR is used to do away with a full mesh of TCP sessions. However, all multicast Join/Prunes transit via it so it increases J/P latency. However, this isn't a new problem specific to multicast in the L3VPN environment. o Multicast Routing update multiplier A single 'multicast route' is stored as "N" instances because BGP tracks the downstream PE which requested a particular tree by creating a different NLRI per downstream PE. For a 1000 PE core, lets say a given multicast stream is received on average by 10 PEs, then there are 10 instances of S,G on RR and upstream PE. If it is received instead by 100 PEs then a given multicast state is represented via 100 NLRI and so on. o Multicast Tunnel Binding state Using existing BGP update filtering techniques does not lend itself to keeping multicast state only along the tree. Bindings are kept on all PEs interested in an RT. This is true even across AS boundaries where a binding generated by a PE of AS 1 may not be used by any PEs in AS 2. But is still present and stored on routers in AS 2. 100 PE core, 100 VPNs, 100 multicast routes. If each PE in the core supports 20 VPNs, then BGP keeps 20*100 extraneous routes on some of them. Nalawade Bhaskar Mehta Section 3.2. [Page 12] ^L INTERNET-DRAFT Expires: March 2006 September 2005 Order of magnitude more - 1000 VPNs, 1000 multicast routes each PE with 200 VPNs -> 200,000 multicast routes in BGP of which some subset are extraneous. The BGP RR would need to store 1000*1000 bindings. This is in addition to multicast routing updates described above. If we do invent new filtering mechanisms for BGP, then it needs to be evaluated as to how significant a change this is and how performance intensive the filtering is. If the filtering is implemented as an inbound filtering mechanism on PEs, then the PEs would be doing extra work to receive and filter out uninteresting updates. And the extra updates still transit the core between all PEs. If the filtering is implemented as an outbound mechanism, the RRs have to do the extra work of filtering out all the updates. This is a big performance load on the RRs. As a result of having numerous different outbound policies, the RRs also lose or have reduced benefit of peer-groups. In case of dynamic filtering mechanisms with finer granularity than just RTs the filter changes would be too frequest and too chatty, again increasing the number of updates and reducing performance. o BGP and PIM interactions are not well understood. Can BGP simply be used for transport or does it need multicast specific extensions. E.g. PIM states for the same group are associated (*,G), (S,G) or (S,G,R) such a concept does not exist in BGP. BGP NLRI are not "related" and do not generaly influence each others state. One open issue this draft does not consider is the mechanism to transition from PIM LAN based procedures to this new form of PE-PE signaling. This is acknowledged as an important piece of the solution going forward and is currently under study. 4. Acknowledgements The authors would like to thank Yiqun Cai and Eric Rosen for their significant contributions. They would also like to thank Arjen Boers, and Gurvinder Singh for their input and feedback. Nalawade Bhaskar Mehta Section 4. [Page 13] ^L INTERNET-DRAFT Expires: March 2006 September 2005 5. Normative References [1] Eric Rosen, Rahul Aggarwal "Multicast in MPLS/BGP IP VPNs", MAY-05,, Work in Progress. [2] Chen Enke, Rekhter Yakov "Cooperative Route Filtering Capability for BGP-4" , Jan 2006. [3] Nalawade Gargi, Kapoor Ruchi "BGPv4 Connector Attribute", OCT-05, , Work in Progress. [4] Nalawade Gargi, Kapoor Ruchi, Dan Tappan, Scott Wainner "BGPv4 Tunnel SAFI", OCT-05, , Work in Progress. [5] Vasseur J., Psenak P., Yasukawa S. "OSPF MPLS Traffic Engineering Capabilities", Feb 2004, Work in Progress. [6] [7] Mark Handley, Bill Fenner, Isidor Kouvelas, Hugh Holbrook, "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", 07-MAR-02, , Work in Progress. [8] 6. Informational References 7. Authors' Addresses Gargi Nalawade gargi@cisco.com cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134 Pranav Mehta pranav@cisco.com cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134 Nidhi Bhaskar Nalawade Bhaskar Mehta Section 7. [Page 14] ^L INTERNET-DRAFT Expires: March 2006 September 2005 nbhaskar@cisco.com cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134 Nalawade Bhaskar Mehta Section 7. [Page 15] ^L INTERNET-DRAFT Expires: March 2006 September 2005 8. Full Copyright Statement Copyright (C) The Internet Society (2005). All Rights Reserved. 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 translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 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. Nalawade Bhaskar Mehta Section 8. [Page 16] ^L INTERNET-DRAFT Expires: March 2006 September 2005 Nalawade Bhaskar Mehta Section 8. [Page 17]