Internet DRAFT - draft-nalawade-l3vpn-mcast-signaling-bgp
draft-nalawade-l3vpn-mcast-signaling-bgp
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,<draft-ietf-l3vpn-2547bis-mcast-00.txt>, Work in Progress.
[2] Chen Enke, Rekhter Yakov "Cooperative Route Filtering Capability for
BGP-4" <draft-ietf-idr-route-filter-12.txt>, Jan 2006.
[3] Nalawade Gargi, Kapoor Ruchi "BGPv4 Connector Attribute", OCT-05,
<draft-nalawade-bgp-connector-00.txt>, Work in Progress.
[4] Nalawade Gargi, Kapoor Ruchi, Dan Tappan, Scott Wainner "BGPv4
Tunnel SAFI", OCT-05, <draft-nalawade-kapoor-bgp-tunnel-safi-04.txt>,
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, <draft-ietf-pim-sm-v2-new-11.txt,.ps>, 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]
