draft-ietf-pim-pop-count-00.txt   draft-ietf-pim-pop-count-01.txt 
Network Working Group Dino Farinacci Network Working Group Dino Farinacci
Internet-Draft Greg Shepherd Internet-Draft Greg Shepherd
Intended status: Experimental cisco Systems Intended status: Experimental Yiqun Cai
Expires: January 29, 2009 July 28, 2008 Expires: January 2, 2010 cisco Systems
July 1, 2009
Population Count Extensions to PIM Population Count Extensions to PIM
draft-ietf-pim-pop-count-00.txt draft-ietf-pim-pop-count-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 29, 2009. This Internet-Draft will expire on January 2, 2010.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This specification defines a method for providing multicast This specification defines a method for providing multicast
distribution-tree accounting data for billing and debugging. Simple distribution-tree accounting data. Simple extensions to the PIM
extensions to the PIM protocol allow a rough approximation of tree- protocol allow a rough approximation of tree-based data in a scalable
based data in a scalable fashion. fashion.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Status of Draft . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. New Hello TLV Pop-Count Support . . . . . . . . . . . . . . . 6 3. New Hello TLV Pop-Count Support . . . . . . . . . . . . . . . 6
4. New Encoded-Source-Address Format . . . . . . . . . . . . . . 7 4. New Pop-Count Join Attribute Format . . . . . . . . . . . . . 7
5. How to use Pop-Count Encoding . . . . . . . . . . . . . . . . 10 5. How to use Pop-Count Encoding . . . . . . . . . . . . . . . . 10
6. Implementation Approaches . . . . . . . . . . . . . . . . . . 11 6. Implementation Approaches . . . . . . . . . . . . . . . . . . 11
7. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
2.1. Status of Draft
This draft was originally written in May of 2004 and presented at the
PIM working group in San Diego in August of 2004. At that time, the
working group was not interested in pursuing this work. At the
Vancouver IETF in December of 2007, there seem to be renewed interest
in the design. So it is being submitted for the working group to
decide if it should become a working group document.
2.2. Overview
This draft proposes a mechanism to convey accounting information This draft proposes a mechanism to convey accounting information
using the PIM protocol [RFC4601] [RFC5015]. Putting the mechanism in using the PIM protocol [RFC4601] [RFC5015]. Putting the mechanism in
PIM allows efficient distribution and maintenance of such accounting PIM allows efficient distribution and maintenance of such accounting
information. Previous mechanisms require data to be correlated from information. Previous mechanisms require data to be correlated from
multiple router sources. multiple router sources.
This proposal allows a single router to be queried to obtain This proposal allows a single router to be queried to obtain
accounting and statistic information for a multicast distribution accounting and statistic information for a multicast distribution
tree as a whole or any distribution sub-tree downstream from a tree as a whole or any distribution sub-tree downstream from a
queried router. The amount of information is fixed and does not queried router. The amount of information is fixed and does not
skipping to change at page 4, line 44 skipping to change at page 4, line 33
1. The number of branches in a distribution tree. 1. The number of branches in a distribution tree.
2. The membership type of the distribution tree, that is SSM or ASM. 2. The membership type of the distribution tree, that is SSM or ASM.
3. Routing domain and time zone boundary information. 3. Routing domain and time zone boundary information.
4. On-tree node and tree diameter counters. 4. On-tree node and tree diameter counters.
5. Effective MTU and bandwidth. 5. Effective MTU and bandwidth.
This draft adds a new Encoded-Source-Address format to the Join/Prune This draft adds a new PIM Join Attribute type [RFC5384] to the Join/
message as well as a new Hello TLV. The mechanism is applicable to Prune message as well as a new Hello TLV. The mechanism is
IPv4 and IPv6 multicast. See [HELLO] for details. applicable to IPv4 and IPv6 multicast.
2.3. Terminology 2.1. Terminology
This section defines the terms used in this draft. This section defines the terms used in this draft.
Multicast Route: A (S,G) or (*,G) entry regardless if the route is Multicast Route: A (S,G) or (*,G) entry regardless if the route is
in ASM, SSM, or Bidir mode of operation. in ASM, SSM, or Bidir mode of operation.
Stub Link: A link with only members joined to the group via IGMP or Stub Link: A link with only members joined to the group via IGMP or
MLD. Which means there are no PIM routers joining for the MLD. Which means there are no PIM routers joining for the
multicast route on the link. multicast route on the link.
skipping to change at page 6, line 8 skipping to change at page 6, line 8
were received on the link). were received on the link).
Dual Link: Is a link in the oif-list which is has the attributes of Dual Link: Is a link in the oif-list which is has the attributes of
a Stub Link *and* Transit Link. That is, there are IGMP and MLD a Stub Link *and* Transit Link. That is, there are IGMP and MLD
members as well as PIM joiners for the multicast route on the members as well as PIM joiners for the multicast route on the
link. link.
3. New Hello TLV Pop-Count Support 3. New Hello TLV Pop-Count Support
When a PIM router sends a Join/Prune message to a neighbor, it will When a PIM router sends a Join/Prune message to a neighbor, it will
use the new form of the Encoded-Source-Address (described in this encode the data in a new PIM Join Attribute type (described in this
draft) when the PIM router determines the neighbor can support this draft) when the PIM router determines the neighbor can support this
draft. If a PIM router supports this draft, it must send the Pop- draft. If a PIM router supports this draft, it must send the Pop-
Count-Supported TLV. The format of the TLV is defined to be: Count-Supported TLV. The format of the TLV is defined to be:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength | | OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue | | OptionValue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OptionType = 26, OptionLength = 8, there is no OptionValue semantics OptionType = 27, OptionLength = 8, there is no OptionValue semantics
defined at this time but will be included for expandability and be defined at this time but will be included for expandability and be
defined in future revisions of this draft. The format will look defined in future revisions of this draft. The format will look
like: like:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 26 | 8 | | 27 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unallocated Flags | | Unallocated Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unallocated Flags: for now should be sent as 0 and ignored on Unallocated Flags: for now should be sent as 0 and ignored on
receipt. This field could be used to enable the use of future receipt. This field could be used to enable the use of future
flags in the Unallocated Flags field of the new Encoded-Source- flags in the Unallocated Flags field of the new Encoded-Source-
Address format defined below. Address format defined below.
4. New Encoded-Source-Address Format 4. New Pop-Count Join Attribute Format
When a PIM router supports this draft and has determined from a When a PIM router supports this draft and has determined from a
received Hello, the neighbor supports this draft, it will send Join/ received Hello, the neighbor supports this draft, it will send Join/
Prune messages with the following format: Prune messages that MAY include a Pop-Count attribute. The mechanism
to process PIM Join Attribute is described in [RFC5384]. The format
of the new attribute is described in the following.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | |F|E| Attr Type | Length | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Effective MTU | Unallocated Flags (Reserved) |P|a|t|A|S| | Unallocated Flags (Reserved) |P|a|t|A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Count | Node Count | Diameter Count| TZ Count | | Domain Count | Node Count | Diameter Count| TZ Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transit Oif-List Count | Stub Oif-List Count | | Transit Oif-List Count | Stub Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Speed Link | Maximum Speed Link | | Minimum Speed Link | Maximum Speed Link |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The above format is used only for entries in the join-list section of The above format is used only for entries in the join-list section of
the Join/Prune message. the Join/Prune message.
The format is identical to the format defined for the Address-Family F bit: 0 Non-Transitive Attribute.
[AFI] independent Encoded-Source-Address in [RFC4601] except there
are additional fields appended. What distinguishes the above format
from the format in [RFC4601] is the use of a different Encoding Type
format. If the Encoding Type value is 1, the above format will be
used.
The additional fields are: E bit: As specified by [RFC5384].
Attr Type: 2.
Length: 16.
Effective MTU: this contains the minimum MTU for any link in the Effective MTU: this contains the minimum MTU for any link in the
oif-list. The sender of Join/Prune message takes the minimum oif-list. The sender of Join/Prune message takes the minimum
value for the MTU (in bytes) from each link in the oif-list. If value for the MTU (in bytes) from each link in the oif-list. If
this value is less than the value stored for the multicast route this value is less than the value stored for the multicast route
(the one received from downstream joiners) then the value should (the one received from downstream joiners) then the value should
be reset and sent in Join/Prune message. Otherwise, the value be reset and sent in Join/Prune message. Otherwise, the value
should remain unchanged. The value is in units of 10s of bytes should remain unchanged.
(i.e. so the value for a traditional Ethernet MTU would be 150).
This provides one to obtain the MTU supported by multicast This provides one to obtain the MTU supported by multicast
distribution tree when examined at the first-hop router(s) or for distribution tree when examined at the first-hop router(s) or for
sub-tree for any router on the distribution tree. sub-tree for any router on the distribution tree.
Unallocated Flags: The flags which are currently not defined. If a Unallocated Flags: The flags which are currently not defined. If a
new flag is defined and sent by a new implementation, an old new flag is defined and sent by a new implementation, an old
implementation should preserve the bit settings. implementation should preserve the bit settings.
S flag: if an IGMPv3 or MLDv2 report was received on any oif-list S flag: if an IGMPv3 or MLDv2 report was received on any oif-list
skipping to change at page 10, line 7 skipping to change at page 10, line 7
stored for the multicast route (the one received from downstream stored for the multicast route (the one received from downstream
joiners) then the value should be reset and sent in Join/Prune joiners) then the value should be reset and sent in Join/Prune
message. Otherwise, the value should remain unchanged. A value message. Otherwise, the value should remain unchanged. A value
of 0 means the link speed is < 1 mbps. of 0 means the link speed is < 1 mbps.
This provides a way to obtain the lowest and highest speed link for This provides a way to obtain the lowest and highest speed link for
the multicast distribution tree. the multicast distribution tree.
5. How to use Pop-Count Encoding 5. How to use Pop-Count Encoding
A router supporting this draft MUST include PIM Join Attribute TLV in
its PIM Hellos. See [RFC5384] and [HELLO] for detail.
It is very important to note that any changes to the values It is very important to note that any changes to the values
maintained in this draft *must not* trigger a new Join/Prune message. maintained in this draft *must not* trigger a new Join/Prune message.
Due to the periodic nature of PIM, the values can be accurately Due to the periodic nature of PIM, the values can be accurately
obtained at 1 minute intervals (or whatever Join/Prune interval obtained at 1 minute intervals (or whatever Join/Prune interval
used). used).
When a router removes a link from an oif-list, it must be able to When a router removes a link from an oif-list, it must be able to
reevaluate the values that it will advertise upstream. This happens reevaluate the values that it will advertise upstream. This happens
when an oif-list entry is timed out or a Prune is received. when an oif-list entry is timed out or a Prune is received.
It is recommended that the Encoded-Source-Address defined in this It is recommended that the Join Attribute defined in this draft be
draft be used for entries in the join-list part of the Join/Prune used for entries in the join-list part of the Join/Prune message. If
message. If the new encoding is used in the prune-list, an the new encoding is used in the prune-list or an Assert message, an
implementation must ignore them but still process the Prune as if it implementation must ignore them but still process the Prune as if it
was in the original encoding described in [RFC4601]. was in the original encoding described in [RFC4601].
It is also recommended that join suppression be disabled on a LAN
when Pop-Count is used.
6. Implementation Approaches 6. Implementation Approaches
An implementation can decide how the accounting attributes are An implementation can decide how the accounting attributes are
maintained. The values can be stored as part of the multicast route maintained. The values can be stored as part of the multicast route
data structure by combining the local information it has with the data structure by combining the local information it has with the
joined information on a per oif basis. So when it is time to send a joined information on a per oif basis. So when it is time to send a
Join/Prune message, the values stored in the multicast route can be Join/Prune message, the values stored in the multicast route can be
copied to the message. copied to the message.
Or, an implementation could store the accounting values per oif and Or, an implementation could store the accounting values per oif and
skipping to change at page 13, line 5 skipping to change at page 13, line 5
However, if there are a contiguous set of routers downstream in the However, if there are a contiguous set of routers downstream in the
distribution tree, they can maintain accounting information for the distribution tree, they can maintain accounting information for the
sub-tree. sub-tree.
If there are a set of contiguous routers supporting this draft If there are a set of contiguous routers supporting this draft
upstream on the multicast distribution tree, accounting information upstream on the multicast distribution tree, accounting information
will be available but it will not represent an accurate assessment of will be available but it will not represent an accurate assessment of
the entire tree. Also, it will not be clear for how much of the the entire tree. Also, it will not be clear for how much of the
distribution tree the accounting information covers. distribution tree the accounting information covers.
8. Security Considerations 8. IANA Considerations
A new PIM Hello Option type needs to be assigned. 29 is proposed in
this draft.
A new PIM Join Attribute type needs to be assigned. 2 is proposed in
this draft.
9. Security Considerations
There are no security considerations for this design other than what There are no security considerations for this design other than what
is already in the main PIM specification [RFC4601]. is already in the main PIM specification [RFC4601].
9. Acknowledgments 10. Acknowledgments
The authors would like to thank John Zwiebel, Amit Jain, and Clayton The authors would like to thank John Zwiebel, Amit Jain, and Clayton
Wagar for their review comments on the initial versions of this Wagar for their review comments on the initial versions of this
draft. draft.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
10.2. Informative References [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format",
RFC 5384, November 2008.
11.2. Informative References
[AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/numbers.html, February 2007. NUMBERS http://www.iana.org/numbers.html, February 2007.
[AMT] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. [AMT] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
Pusateri, "Automatic IP Multicast Without Explicit Pusateri, "Automatic IP Multicast Without Explicit
Tunnels (AMT)", draft-ietf-mboned-auto-multicast-08.txt Tunnels (AMT)", draft-ietf-mboned-auto-multicast-08.txt
(work in progress), October 2007. (work in progress), October 2007.
[HELLO] IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per [HELLO] IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per
skipping to change at page 17, line 5 skipping to change at page 17, line 23
Email: dino@cisco.com Email: dino@cisco.com
Greg Shepherd Greg Shepherd
cisco Systems cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: shep@cisco.com Email: shep@cisco.com
Full Copyright Statement Yiqun Cai
cisco Systems
Copyright (C) The IETF Trust (2008). Tasman Drive
San Jose, CA 95134
This document is subject to the rights, licenses and restrictions USA
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF Email: ycai@cisco.com
Administrative Support Activity (IASA).
 End of changes. 32 change blocks. 
105 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/