draft-ietf-idmr-cbt-spec-v3-00.txt   draft-ietf-idmr-cbt-spec-v3-01.txt 
Inter-Domain Multicast Routing (IDMR) A. Ballardie Inter-Domain Multicast Routing (IDMR) A. Ballardie
INTERNET-DRAFT Consultant INTERNET-DRAFT Consultant
B. Cain B. Cain
Bay Networks Bay Networks
Z. Zhang Z. Zhang
Bay Networks Bay Networks
March 1998 August 1998
Core Based Trees (CBT version 3) Multicast Routing Core Based Trees (CBT version 3) Multicast Routing
-- Protocol Specification -- -- Protocol Specification --
<draft-ietf-idmr-cbt-spec-v3-00.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working doc- This document is an Internet Draft. Internet Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its Areas, and uments of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute work- its Working Groups. Note that other groups may also distribute work-
ing documents as Internet Drafts). ing documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet other documents at any time. It is not appropriate to use Internet
skipping to change at page 2, line 27 skipping to change at page 2, line 27
2. Building a CBT Multicast Domain ................................ 5 2. Building a CBT Multicast Domain ................................ 5
3. Introduction & Terminology ..................................... 5 3. Introduction & Terminology ..................................... 5
4. CBT Functional Overview ........................................ 6 4. CBT Functional Overview ........................................ 6
4.1. The First Step: Joining the Tree .......................... 6 4.1. The First Step: Joining the Tree .......................... 6
4.2. Transient State ........................................... 7 4.2. Transient State ........................................... 7
4.3. Getting on-tree ........................................... 7 4.3. Getting on-tree ........................................... 8
4.3. Pruning & Prune State ..................................... 8 4.3. Pruning & Prune State ..................................... 8
4.4. The Forwarding Cache ...................................... 9 4.4. The Forwarding Cache ...................................... 9
4.5. Packet Forwarding ......................................... 11 4.5. Packet Forwarding ......................................... 11
4.7. The "Keepalive" Protocol .................................. 11 4.7. The "Keepalive" Protocol .................................. 11
4.8. Control Message Precedence & Forwarding Criteria .......... 12 4.8. Control Message Precedence & Forwarding Criteria .......... 12
4.9. Broadcast LANs ............................................ 13 4.9. Broadcast LANs ............................................ 14
4.10. The "all-cbt-routers" Group .............................. 14 4.10. The "all-cbt-routers" Group .............................. 15
4.11. Non-Member Sending ....................................... 15 4.11. Non-Member Sending ....................................... 15
5. Protocol Specification Details ................................. 15 5. Protocol Specification Details ................................. 15
5.1. CBT HELLO Protocol ........................................ 15 5.1. CBT HELLO Protocol ........................................ 16
5.1.1. Sending HELLOs ..................................... 16 5.1.1. Sending HELLOs ..................................... 17
5.1.2. Receiving HELLOs ................................... 17 5.1.2. Receiving HELLOs ................................... 17
5.2. JOIN_REQUEST Processing ................................... 19 5.2. JOIN_REQUEST Processing ................................... 20
5.2.1. Sending JOIN_REQUESTs .............................. 19 5.2.1. Sending JOIN_REQUESTs .............................. 20
5.2.2. Receiving JOIN_REQUESTs ............................ 19 5.2.2. Receiving JOIN_REQUESTs ............................ 20
5.2.3. Additional Aspects Related to Receiving Multicast 5.2.3. Additional Aspects Related to Receiving Multicast
JOIN_REQUESTs ............................................. 20 JOIN_REQUESTs ............................................. 21
5.3. JOIN_ACK Processing ....................................... 20 5.3. JOIN_ACK Processing ....................................... 21
5.3.1. Sending JOIN_ACKs .................................. 20 5.3.1. Sending JOIN_ACKs .................................. 21
5.3.2. Receiving JOIN_ACKs ................................ 21 5.3.2. Receiving JOIN_ACKs ................................ 22
5.4. QUIT_NOTIFICATION Processing .............................. 21 5.4. QUIT_NOTIFICATION Processing .............................. 22
5.4.1. Sending QUIT_NOTIFICATIONs ......................... 21 5.4.1. Sending QUIT_NOTIFICATIONs ......................... 22
5.4.2. Receiving QUIT_NOTIFICATIONs ....................... 22 5.4.2. Receiving QUIT_NOTIFICATIONs ....................... 23
5.5. ECHO_REQUEST Processing ................................... 23 5.5. ECHO_REQUEST Processing ................................... 24
5.5.1. Sending ECHO_REQUESTs .............................. 23 5.5.1. Sending ECHO_REQUESTs .............................. 24
5.5.2. Receiving ECHO_REQUESTs ............................ 23 5.5.2. Receiving ECHO_REQUESTs ............................ 24
5.6. ECHO_REPLY Processing ..................................... 24 5.6. ECHO_REPLY Processing ..................................... 25
5.6.1. Sending ECHO_REPLYs ................................ 24 5.6.1. Sending ECHO_REPLYs ................................ 25
5.6.2. Receiving ECHO_REPLYs .............................. 24 5.6.2. Receiving ECHO_REPLYs .............................. 25
5.7. FLUSH_TREE Processing ..................................... 25 5.7. FLUSH_TREE Processing ..................................... 26
5.7.1. Sending FLUSH_TREE messages ........................ 25 5.7.1. Sending FLUSH_TREE messages ........................ 26
5.7.2. Receiving FLUSH_TREE messages ...................... 25 5.7.2. Receiving FLUSH_TREE messages ...................... 26
6. Timers and Default Values ...................................... 26 6. Timers and Default Values ...................................... 27
7. CBT Packet Formats and Message Types ........................... 27 7. CBT Packet Formats and Message Types ........................... 28
7.1. CBT Common Control Packet Header .......................... 27 7.1. CBT Common Control Packet Header .......................... 28
7.2. Packet Format for CBT Control Packet Types 0 - 6 .......... 28 7.2. Packet Format for CBT Control Packet Types 0 - 6 .......... 29
7.2.1. Option Type Definitions ............................ 29 7.2.1. Option Type Definitions ............................ 30
8. Core Router Discovery .......................................... 30 7.2.2. Sample Control Packets ............................. 31
8.1. "Bootstrap" Mechanism Overview ............................ 30 8. Core Router Discovery .......................................... 33
8.2. Bootstrap Message Format .................................. 32 8.1. "Bootstrap" Mechanism Overview ............................ 34
8.3. Candidate Core Advertisement Message Format ............... 32 8.2. Bootstrap Message Format .................................. 35
Acknowledgements .................................................. 32 8.3. Candidate Core Advertisement Message Format ............... 36
References ........................................................ 33 Acknowledgements .................................................. 36
Author Information ................................................ 34 References ........................................................ 37
Author Information ................................................ 38
1. Changes from RFC 2189 1. Changes from RFC 2189
+o forwarding cache support for entries of different granularities, +o forwarding cache support for entries of different granularities,
i.e. (*, G), (*, Core), or (S, G), and support for S and/or G masks i.e. (*, G), (*, Core), or (S, G), and support for S and/or G masks
for representing S and/or G aggregates for representing S and/or G aggregates
+o included support for joins, quits (prunes), and flushes of differ- +o included support for joins, quits (prunes), and flushes of differ-
ent granularities, i.e. (*, G), (*, Core), or (S, G), where S ent granularities, i.e. (*, G), (*, Core), or (S, G), where S
and/or G can be aggregates and/or G can be aggregates
skipping to change at page 6, line 20 skipping to change at page 6, line 20
4.1. The First Step: Joining the Tree 4.1. The First Step: Joining the Tree
As a first step, a host first expresses its interest in joining a As a first step, a host first expresses its interest in joining a
group by multicasting an IGMP host membership report [3] across its group by multicasting an IGMP host membership report [3] across its
attached link. Note that all CBT routers, similar to other multicast attached link. Note that all CBT routers, similar to other multicast
protocol routers, are expected to participate in IGMP for the purpose protocol routers, are expected to participate in IGMP for the purpose
of monitoring directly attached group memberships, and acting as IGMP of monitoring directly attached group memberships, and acting as IGMP
querier should the need arise. querier should the need arise.
On receiving an IGMP Group Membership Report, a local CBT router On receiving an IGMP Host Membership Report, a local CBT router
invokes the tree joining process (unless it has already) by generat- invokes the tree joining process (unless it has already) by generat-
ing a JOIN_REQUEST message, which is sent to the next hop on the path ing a JOIN_REQUEST message, which is sent to the next hop on the path
towards the group's core router (how the local router discovers which towards the group's core router (how the local router discovers which
core to join is discussed in section 8). This join message must be core to join is discussed in section 8). This join message must be
explicitly acknowledged (JOIN_ACK) either by the core router itself, explicitly acknowledged (JOIN_ACK) either by the core router itself,
or by another router that is on the path between the sending router or by another router that is on the path between the sending router
and the core, which itself has already successfully joined the tree. and the core, which itself has already successfully joined the tree.
By default, joins/join-acks create bi-directional forwarding state, By default, joins/join-acks create bi-directional forwarding state,
i.e. data can flow in the direction downstream -> upstream, or i.e. data can flow in the direction downstream -> upstream, or
upstream -> downstream. In some circumstances a join/join-ack may upstream -> downstream. In some circumstances a join/join-ack may
include an option which results in uni-directional forwarding state; include an option which instantiates uni-directional forwarding
an interface over which a uni-directional join-ack is forwarded (not state; an interface over which a uni-directional join-ack is for-
received) is marked as pruned. Data is permitted to be received via warded (not received) is automatically marked as pruned. Data is
a pruned interface, but must not be forwarded over a pruned inter- permitted to be received via a pruned interface, but must not be for-
face. Prune state can also be instantiated by the QUIT_NOTIFICATION warded over a pruned interface. Prune state can also be instantiated
message (see section 4.8). by the QUIT_NOTIFICATION message (see section 4.8).
A join-request is made uni-directional by the inclusion of the "uni- A join-request is made uni-directional by the inclusion of the "uni-
directional" join option (see section 7.2.1), which is copied to the directional" join option (see section 7.2.1), which is copied to the
corresponding join-ack; join-request options are always copied to the corresponding join-ack; join-request options are always copied to the
corresponding join-ack. corresponding join-ack.
CBT now supports source specific joins/prunes so as to be better CBT now supports source specific joins/prunes so as to be better
equipped when deployed in a transit domain; source specific control equipped when deployed in a transit domain; source specific control
messages are only ever generated by CBT Border Routers (BRs). Source messages are only ever generated by CBT Border Routers (BRs). Source
specific control messages follow G, not S, i.e. they are routed specific control messages follow G, not S, i.e. they are routed
skipping to change at page 7, line 21 skipping to change at page 7, line 21
originates it (a LAN's designated router (DR)) and the routers it originates it (a LAN's designated router (DR)) and the routers it
traverses (an exception is described in section 4.9), and this state traverses (an exception is described in section 4.9), and this state
consists of <group, [source], downstream address, upstream address>; consists of <group, [source], downstream address, upstream address>;
"source" is optional, and relevant only to source specific control "source" is optional, and relevant only to source specific control
messages. messages.
On broadcast networks "downstream address" is the local IP address of On broadcast networks "downstream address" is the local IP address of
the interface over which this router received the join (or IGMP Host the interface over which this router received the join (or IGMP Host
Membership Report), and "upstream address" is the local IP address of Membership Report), and "upstream address" is the local IP address of
the interface over which this router forwarded the join (according to the interface over which this router forwarded the join (according to
unicast routing). On non-broadcast networks "downstream address" is this router's routing table). On non-broadcast networks "downstream
the IP address of the join's previous hop, and "upstream address" is address" is the IP address of the join's previous hop, and "upstream
the IP address of the next hop (according to unicast routing). Tran- address" is the IP address of the next hop (according to this
sient state eventually times out unless the join is explicitly router's routing table). Transient state eventually times out unless
acknowledged. When a join is acknowledged, the transient join state the join is explicitly acknowledged. When a join is acknowledged, the
is transferred to the router's multicast forwarding cache. transient join state is transferred to the router's multicast for-
warding cache, thus becoming "permanent".
If "downstream address" implies a broadcast LAN, the transient state If "downstream address" implies a broadcast LAN, the transient state
MUST be able to distinguish between a member host being reachable MUST be able to distinguish between a member host being reachable
over that interface, and a downstream router being reachable over over that interface, and a downstream router being reachable over
that interface. This is necessary so that, on receipt of a JOIN_ACK, that interface. This is necessary so that, on receipt of a JOIN_ACK,
a router with transient state knows whether "downstream address" only a router with transient state knows whether "downstream address" only
leads to a group member, in which case the JOIN_ACK is not forwarded, leads to a group member, in which case the JOIN_ACK need not be for-
or whether "downstream address" leads to a downstream router that warded, or whether "downstream address" leads to a downstream router
either originated or forwarded the join prior to this router receiv- that either originated or forwarded the join prior to this router
ing it, in which case this router must forward a received JOIN_ACK. receiving it, in which case this router must forward a received
Precisely how this distinction is made is implementation dependent. A JOIN_ACK. Precisely how this distinction is made is implementation
router must also be able to distinguish these two conditions wrt its dependent. A router must also be able to distinguish these two condi-
forwarding cache. tions wrt its forwarding cache.
4.3. Getting "On-tree" 4.3. Getting "On-tree"
A router which terminates a JOIN_REQUEST (see section 4.8) sends a A router which terminates a JOIN_REQUEST (see section 4.8) sends a
JOIN_ACK in response. A join acknowledgement (JOIN_ACK) traverses JOIN_ACK in response. A join acknowledgement (JOIN_ACK) traverses
the reverse path of the corresponding join message, which is possible the reverse path of the corresponding join message, which is possible
due to the presence of the transient join state. Once the acknowl- due to the presence of the transient join state. Once the acknowl-
edgement reaches the router that originated the join message, the new edgement reaches the router that originated the join message, the new
receiver can receive traffic sent to the group. receiver can receive traffic sent to the group.
skipping to change at page 8, line 25 skipping to change at page 8, line 30
which may lead to the creation of tree loops are avoided. For exam- which may lead to the creation of tree loops are avoided. For exam-
ple, if a router's parent router for a group becomes unreachable, the ple, if a router's parent router for a group becomes unreachable, the
router (child) immediately "flushes" all of its downstream branches, router (child) immediately "flushes" all of its downstream branches,
allowing them to individually rejoin if necessary. Transient unicast allowing them to individually rejoin if necessary. Transient unicast
loops do not pose a threat because a new join message that loops back loops do not pose a threat because a new join message that loops back
on itself will never get acknowledged, and thus eventually times out. on itself will never get acknowledged, and thus eventually times out.
4.4. Pruning and Prune State 4.4. Pruning and Prune State
Any of a forwarding cache entry's children can be "pruned" by the Any of a forwarding cache entry's children can be "pruned" by the
immediate downstream router (child). In CBT, pruning is implemented immediate downstream router (child); in CBT, pruning is implemented
by means of the QUIT_NOTIFICATION message, which is sent hop-by-hop by means of the QUIT_NOTIFICATION message, which is sent hop-by-hop
in the direction: downstream --> upstream. A pruned child must be in the direction: downstream --> upstream. A pruned child must be
distinguishable from a non-pruned child - how is implementation distinguishable from a non-pruned child - how is implementation
dependent. One possible way would be to associate a "prune bit" with dependent. One possible way would be to associate a "prune bit" with
each child in the forwarding cache. each child in the forwarding cache.
The granularity of a quit (prune) can be (*, G), (*, Core), or (S, The granularity of a quit (prune) can be (*, G), (*, Core), or (S,
G). (*, Core) and (S, G) prunes are only relevant to core tree G). (*, Core) and (S, G) prunes are only relevant to core tree
branches, i.e. those routers between a CBT BR and a core (inclu- branches, i.e. those routers between a CBT BR and a core (inclu-
sive). (*, G) prunes are applicable anywhere on a CBT tree. sive). (*, G) prunes are applicable anywhere on a CBT tree.
In previous versions of CBT, a quit was sent by a child router to
cause its parent to remove it from the tree. Whilst this capability
remains, in this version of CBT a quit can also be sent by a child to
make the parent's forwarding state more specific.
Refer to section 4.8 for the procedures relating to receiving and Refer to section 4.8 for the procedures relating to receiving and
forwarding a quit (prune) message. forwarding a quit (prune) message.
Data is permitted to be received via a pruned interface, but must not Data is permitted to be received via a pruned interface, but must not
be forwarded over a pruned interface. Thus, pruning is always uni- be forwarded over a pruned interface. Thus, pruning is always uni-
directional - it can stop data flowing downstream, but does not pre- directional - it can stop data flowing downstream, but does not pre-
vent data from flowing upstream. vent data from flowing upstream.
CBT BRs are able to take advantage of this uni-directionality; if the CBT BRs are able to take advantage of this uni-directionality; if the
BR does not have any directly attached group members, and is not BR does not have any directly attached group members, and is not
serving a neighbouring domain with group traffic, it can elect not to serving a neighbouring domain with group traffic, it can elect not to
receive traffic for the group sourced inside, or received via, the receive traffic for the group which is sourced inside, or received
CBT domain. At the same time, if the BR is the ingress BR for a par- via, the CBT domain. At the same time, if the BR is the ingress BR
ticular (*, G), or (S, G), externally sourced traffic for (*, G) or for a particular (*, G), or (S, G), externally sourced traffic for
(S, G) need not be encapsulated by the ingress BR and unicast to the (*, G) or (S, G) need not be encapsulated by the ingress BR and uni-
relevant core router - the BR can send the traffic using native IP cast to the relevant core router - the BR can send the traffic using
multicast. native IP multicast.
4.5. The Forwarding Cache 4.5. The Forwarding Cache
A CBT router MUST implement a multicast forwarding cache which sup- A CBT router MUST implement a multicast forwarding cache which sup-
ports source specific (i.e. (S, G)) as well as source independent ports source specific (i.e. (S, G)) as well as source independent
(i.e. (*, G) and (*, Core)) entries. This forwarding cache is known (i.e. (*, G) and (*, Core)) entries. This forwarding cache is known
as the router's private CBT forwarding cache, or PFC. as the router's private CBT forwarding cache, or PFC.
All implementations SHOULD also implement a shared (i.e. protocol All implementations SHOULD also implement a shared (i.e. protocol
independent) multicast forwarding cache - recommended in [8] to independent) multicast forwarding cache - recommended in [8] to
skipping to change at page 9, line 42 skipping to change at page 10, line 8
individual Class D 32-bit group address, or may be a prefix repre- individual Class D 32-bit group address, or may be a prefix repre-
senting a contiguous range of group addresses (a group aggregate). senting a contiguous range of group addresses (a group aggregate).
Similarly, for source specific PFC entries, S can be an aggregate. Similarly, for source specific PFC entries, S can be an aggregate.
Therefore, the PFC SHOULD support the inclusion of masks or mask Therefore, the PFC SHOULD support the inclusion of masks or mask
lengths to be associated with each of S and G. lengths to be associated with each of S and G.
In CBT, all PFC entries require that an entry's "upstream" interface In CBT, all PFC entries require that an entry's "upstream" interface
is distinguishable as such - how is implementation dependent. CBT is distinguishable as such - how is implementation dependent. CBT
uses the term "parent" interchangeably with "upstream", and uses the term "parent" interchangeably with "upstream", and
"child/children" interchangeably with "downstream". "child/children" interchangeably with "downstream". A core router's
parent is always NULL.
Whenever the sending/receiving of a CBT join or prune results in the Whenever the sending/receiving of a CBT join or prune results in the
instantiation of more specific state in the router (e.g. (*, Core) instantiation of more specific state in the router (e.g. (*, Core)
state exists, then a (*, G) join arrives), the children of the new state exists, then a (*, G) join arrives), the children of the new
entry represent the union of the children from all other less spe- entry represent the union of the children from all other less spe-
cific forwarding cache entries, as well as the child (interface) over cific forwarding cache entries, as well as the child (interface) over
which the message was received (if not already included). This is so which the message was received (if not already included). This is so
that at most a single forwarding cache entry need be matched with an that at most a single forwarding cache entry need be matched with an
incoming packet. incoming packet.
skipping to change at page 11, line 5 skipping to change at page 11, line 15
Wrt R4's (s1, g1) entry, it is not possible for R4 to determine which Wrt R4's (s1, g1) entry, it is not possible for R4 to determine which
is the correct incoming interface for s1 traffic, since R2 may send is the correct incoming interface for s1 traffic, since R2 may send
s1 traffic towards the core, or towards R3. Thus, R4 may receive (s1, s1 traffic towards the core, or towards R3. Thus, R4 may receive (s1,
g1) traffic via any of its on-tree interfaces, though R4 will not g1) traffic via any of its on-tree interfaces, though R4 will not
forward the traffic over a pruned child. forward the traffic over a pruned child.
A forwarding cache entry whose children are ALL marked as pruned as a A forwarding cache entry whose children are ALL marked as pruned as a
result of receiving quit messages may delete the entry provided there result of receiving quit messages may delete the entry provided there
exists no less specific state with at least one non-pruned child. exists no less specific state with at least one non-pruned child.
A core router's "parent" is always NULL.
4.6. Packet Forwarding 4.6. Packet Forwarding
When a data packet arrives, the forwarding cache is searched for a When a data packet arrives, the forwarding cache is searched for a
best matching (according to longest match) entry. If no match is best matching (according to longest match) entry. If no match is
found the packet is discarded. If the packet arrived natively it is found the packet is discarded. If the packet arrived natively it is
accepted if it arrives via an on-tree interface, i.e. any interface accepted if it arrives via an on-tree interface, i.e. any interface
listed in a matching entry, otherwise the packet is discarded. Assum- listed in a matching entry, otherwise the packet is discarded. Assum-
ing the packet is accepted, a copy of the packet is forwarded over ing the packet is accepted, a copy of the packet is forwarded over
each other (outgoing) non-pruned interface listed in the matching each other (outgoing) non-pruned interface listed in the matching
entry. entry.
skipping to change at page 21, line 7 skipping to change at page 22, line 7
5.3.1. Sending JOIN_ACKs 5.3.1. Sending JOIN_ACKs
A router which terminates a JOIN_REQUEST (see section 4.8) sends a A router which terminates a JOIN_REQUEST (see section 4.8) sends a
JOIN_ACK in response. A JOIN_ACK is sent over the same interface as JOIN_ACK in response. A JOIN_ACK is sent over the same interface as
the corresponding JOIN_REQUEST was received. Any options present in the corresponding JOIN_REQUEST was received. Any options present in
the join must be copied to the join-ack. the join must be copied to the join-ack.
The sending of a JOIN_ACK - which inlcudes the "uni-directional" The sending of a JOIN_ACK - which inlcudes the "uni-directional"
option - over a child results in the child being pruned. The sending option - over a child results in the child being pruned. The sending
of a JOIN_ACK - which includes no options - over a child that is of a JOIN_ACK over a child that is marked as pruned results in that
marked as pruned results in that child being "un-pruned". child being "un-pruned", unless the join-ack contains the uni-direc-
tional option.
5.3.2. Receiving JOIN_ACKs 5.3.2. Receiving JOIN_ACKs
An arriving JOIN_ACK must be matched to the corresponding <group, An arriving JOIN_ACK must be matched to the corresponding <group,
[source], downstream address, upstream address> from the router's [source], downstream address, upstream address> from the router's
cached transient state. If no match is found, the JOIN_ACK is dis- cached transient state. If no match is found, the JOIN_ACK is dis-
carded. If a match is found, a CBT forwarding cache entry is created carded. If a match is found, a CBT forwarding cache entry is created
(or updated) by transferring the necessary transient join state to (or updated) by transferring the necessary transient join state to
the router's forwarding cache. The interface over which the join-ack the router's forwarding cache. The interface over which the join-ack
arrives becomes the entry's parent. arrives becomes the entry's parent.
If the router's transient join state indicates that a router is pre- If the router's transient join state indicates that a router is pre-
sent downstream, it forwards the join-ack accordingly. A join-ack is sent downstream, it forwards the join-ack accordingly. A join-ack is
not forwarded downstream if this router's transient state indicates not forwarded downstream if this router's transient state indicates
ONLY group member hosts reside downstream (as opposed to router(s)). ONLY group member hosts reside downstream (as opposed to router(s)).
A router's transient and forwarding states MUST be able to distin- An implementation SHOULD be able to distinguish these two conditions.
guish these two conditions.
Once transient state has been confirmed by transferring it to the Once transient state has been confirmed by transferring it to the
forwarding cache, the transient state is deleted. forwarding cache, the transient state is deleted.
5.4. QUIT_NOTIFICATION Processing 5.4. QUIT_NOTIFICATION Processing
A QUIT_NOTIFICATION (quit or prune) is both a means of improving, A QUIT_NOTIFICATION (quit or prune) is both a means of improving,
i.e. speeding up, group leave latency for CBT leaf routers, and a i.e. speeding up, group leave latency for CBT leaf routers, and a
means for CBT Border Routers to elect not to receive traffic either means for CBT Border Routers to elect not to receive traffic either
from sources within, or via, the CBT domain. from sources within, or via, the CBT domain.
A quit (prune) can be of (*, G), (*, Core), or (S, G) granularity. A A quit (prune) can be of (*, G), (*, Core), or (S, G) granularity. A
single quit message can carry information representing multiple dif- single quit message can carry information representing multiple dif-
ferent states. ferent states.
5.4.1. Sending QUIT_NOTIFICATIONs 5.4.1. Sending QUIT_NOTIFICATIONs
A CBT router *originates* a QUIT_NOTIFICATION of the relevant granu- A CBT router *originates* a QUIT_NOTIFICATION of the relevant granu-
larity when all children of a forwarding cache entry become pruned, larity when all children of a forwarding cache entry become pruned,
AND there exists no less specific state with at least one other non- AND there exists no less specific state with at least one _other_
pruned child. non-pruned child.
Forwarding rules for a quit are explained in section 4.8. Forwarding rules for a quit are explained in section 4.8.
A QUIT_NOTIFICATION is not acknowledged. A QUIT_NOTIFICATION is not acknowledged.
To help ensure consistency between a child and parent router given the To help ensure consistency between a child and parent router given the
potential for loss of a QUIT_NOTIFICATION, a total of [MAX_RTX] potential for loss of a QUIT_NOTIFICATION, a total of [MAX_RTX]
QUIT_NOTIFICATIONs are sent, each HOLDTIME seconds after the previous QUIT_NOTIFICATIONs are sent, each HOLDTIME seconds after the previous
one. one.
skipping to change at page 24, line 11 skipping to change at page 25, line 11
Whenever an ECHO_REQUEST is received on an interface, if the router's Whenever an ECHO_REQUEST is received on an interface, if the router's
interface is a parent interface for the reported state(s) it resets interface is a parent interface for the reported state(s) it resets
its [ECHO_INTERVAL] timer on that interface for those state(s), if its [ECHO_INTERVAL] timer on that interface for those state(s), if
appropriate. This implies that an ECHO_REQUEST which is multicast on appropriate. This implies that an ECHO_REQUEST which is multicast on
a LAN suppresses the ECHO_REQUEST that is about to be sent by another a LAN suppresses the ECHO_REQUEST that is about to be sent by another
router(s) for the same state(s) over the same interface. router(s) for the same state(s) over the same interface.
If the router's receiving interface is a child interface for the If the router's receiving interface is a child interface for the
reported state(s), it resets its [DOWNSTREAM_EXPIRE_TIME] timer on reported state(s), it resets its [DOWNSTREAM_EXPIRE_TIME] timer on
that interface for those state(s), if appropriate, and sends an that interface for those state(s), if appropriate, and sends (multi-
ECHO_REPLY to the same child reporting all states for which this cast) an ECHO_REPLY reporting all states for which this router con-
router is the parent for that child. siders itself the parent wrt the child (interface).
Failure to receive an ECHO_REQUEST for a state(s) from a child after Failure to receive an ECHO_REQUEST for a state(s) from a child after
[DOWNSTREAM_EXPIRE_TIME] results in the immediate removal of the [DOWNSTREAM_EXPIRE_TIME] results in the immediate removal of the
child from the relevant forwarding cache entry if the child is reach- child from the relevant forwarding cache entry if the child is reach-
able via a non-broadcast network. If the child is reachable via a able via a non-broadcast network. If the child is reachable via a
broadcast network, the expiry of [DOWNSTREAM_EXPIRE_TIME] results in broadcast network, the expiry of [DOWNSTREAM_EXPIRE_TIME] results in
the removal of the child from the router's relevant forwarding cache the removal of the child from the router's relevant forwarding cache
entry only if the router is sure no other downstream on-tree routers entry provided no group members are present on that interface.
are reachable via the same interface, and no group members are pre-
sent on that interface.
5.6. ECHO_REPLY Processing 5.6. ECHO_REPLY Processing
ECHO_REPLY messages are sent in immediate response to ECHO_REQUEST ECHO_REPLY messages are sent in immediate response to ECHO_REQUEST
messages received over a valid child interface for the reported messages received over a valid child interface for the reported
state(s). The ECHO_REPLY reports all state(s) for which this router state(s). The ECHO_REPLY reports all state(s) for which this router
considers itself the parent to the echo-requesting child. considers itself the parent to the echo-requesting child.
A single ECHO_REPLY can carry information representing multiple dif- If multiple states need reporting, one or more ECHO_REPLYs may be
ferent states. sent in response to a single ECHO_REQUEST, as necessary.
5.6.1. Sending ECHO_REPLY messages 5.6.1. Sending ECHO_REPLY messages
An ECHO_REPLY message is sent in immediate response to receiving an An ECHO_REPLY message is sent in immediate response to receiving an
ECHO_REQUEST message via one of this router's valid children for the ECHO_REQUEST message via one of this router's valid children for the
reported state(s). The ECHO_REPLY contains a list of all states for reported state(s). The ECHO_REPLY(s) contains a list of all states
which this router considers itself the parent to the child. for which this router considers itself the parent to the child.
5.6.2. Receiving ECHO_REPLY messages 5.6.2. Receiving ECHO_REPLY messages
For each state reported in an ECHO_REPLY message received from a For each state reported in an ECHO_REPLY message received from a
valid parent, the timers [UPSTREAM_EXPIRE_TIME] and [ECHO_INTERVAL] valid parent, the timers [UPSTREAM_EXPIRE_TIME] and [ECHO_INTERVAL]
are refreshed for the reported states. are refreshed for the reported states.
Failure to receive the relevant ECHO_REPLY [HOLDTIME] seconds after Failure to receive the relevant ECHO_REPLY [HOLDTIME] seconds after
sending an ECHO_REQUEST results in the corresponding ECHO_REQUEST sending an ECHO_REQUEST results in the corresponding ECHO_REQUEST
being resent. An ECHO_REQUEST can be resent a maximum of [MAX_RTX] being resent. An ECHO_REQUEST can be resent a maximum of [MAX_RTX]
skipping to change at page 28, line 10 skipping to change at page 29, line 10
+o type 8: Candidate Core Advertisement (optional) +o type 8: Candidate Core Advertisement (optional)
+o Addr Length: address length in bytes of unicast or multicast +o Addr Length: address length in bytes of unicast or multicast
addresses carried in the control packet. addresses carried in the control packet.
+o Checksum: the 16-bit one's complement of the one's complement sum +o Checksum: the 16-bit one's complement of the one's complement sum
of the entire CBT control packet. of the entire CBT control packet.
7.2. Packet Format for CBT Control Packet Types 0 - 6 7.2. Packet Format for CBT Control Packet Types 0 - 6
The following packet format is used on CBT control packet types 0 - A CBT control packet is divided into 3 parts:
6. For the format of CBT "Bootstrap" control packets, see section 8
below. +o Common Control Packet Header,
+o Control Packet Payload, and
+o Control Packet Option(s).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common
| CBT Control Packet Header | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
|Payload Length | # of options | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control
| address #1 | Packet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload
| address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT Control Packet Header | | address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
| # of groups | # of options | reserved | | option type | option len | option value... | Option(s)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group (or Core) address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option type | option len | option value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. CBT Control Packet Format for Types 0 - 6. Figure 6. CBT Control Packet Format for Types 0 - 6.
Control Packet Field Definitions: Control Packet Field Definitions:
+o # of groups: the number of individual (non-contiguous, or set of +o # Payload Length: the length of the CBT control packet payload,
contiguous) groups that are included in the main body of this mes- excluding the common control packet header and option(s).
sage.
+o # of options: the number of distinct options (as defined by option +o # of options: the number of distinct options (as defined by option
type) carried in this control packet. type) carried in this control packet.
+o group address #n: multicast group address. A control packet repre- +o address #n: control packet payload address(es). Different control
senting all groups associated with a core router (*, Core) includes packet types can carry addresses (multicast and/or unicast) as
only one group address field which contains the unicast IP address their payload (e.g. JOIN_REQUESTs), and some control packet types
of the relevant core router. Any group(s) exempted from those rep- carry no addresses in the payload (e.g. HELLOs).
resented in the main body of the message i.e. groups for which this
message should not apply, are represented using option type 4 (see
below).
+o option type: unique option identifier. +o option type: unique option identifier.
+o option len: option length. The number of bytes consumed by this +o option len: option length. The number of bytes consumed by this
option's value. option's value.
+o option value: variable length option value. +o option value: variable length option value.
NOTE: all control messages are padded to a 32-bit boundary. NOTE: all control messages are padded to a 32-bit boundary.
skipping to change at page 29, line 27 skipping to change at page 30, line 28
denote this HELLO packet's preference value. This option consumes 1 denote this HELLO packet's preference value. This option consumes 1
byte of "option value". byte of "option value".
+o type 2: Uni-directional. Applicable only to JOIN_REQUESTs to indi- +o type 2: Uni-directional. Applicable only to JOIN_REQUESTs to indi-
cate a uni-directional join. cate a uni-directional join.
+o type 3: Inclusion List. Enables the reporting of a contiguous set +o type 3: Inclusion List. Enables the reporting of a contiguous set
of groups using a group mask, for which this control message should of groups using a group mask, for which this control message should
apply. The mask is represented by an 8-bit "masklen" field which apply. The mask is represented by an 8-bit "masklen" field which
is always included as the first 8 bits of this option's value. One is always included as the first 8 bits of this option's value. One
or more group prefixes follow, padded out (zeroed) to 32 bits. or more group prefixes follow, each padded out (zeroed) to 32 bits.
+o type 4: Exclusion List. This option allows for the reporting of +o type 4: Exclusion List. This option allows for the reporting of
group(s) to be exempted from the set reported elsewhere in this group(s) to be exempted from the set reported elsewhere in this
control packet. A contiguous range of groups may be specified control packet. A contiguous range of groups may be specified
using a group mask. The mask is represented by an 8-bit "masklen" using a group mask. The mask is represented by an 8-bit "masklen"
field which is always included as the first 8 bits of this option's field which is always included as the first 8 bits of this option's
value. One or more group prefixes follow, padded out (zeroed) to value. One or more group prefixes follow, each padded out (zeroed)
32 bits. to 32 bits.
+o type 5: (Source, Group) Info. This option enables a control message +o type 5: Source Information. This option enables a control message
to report source specific group information, e.g. it is used on (S, to specify source(s) to be associated with a group(s) carried else-
G) joins, (S, G) quits, and (S, G) flushes. where in the control message; if this option is specified as the
first option after the control packet payload, the source informa-
tion applies to the group specified in the payload. If this source
information is to apply to a group aggregate (as specified by
option type 3), the option specifying the group prefix MUST appear
immediately before this option.
The first 8 bits of this option's value represent the number of A source aggregate (prefix) may be specified using a source mask.
distinct (source, group) pairs ("# (S,G)") contained in this The mask is represented by an 8-bit "masklen" field which is always
option. included as the first 8 bits of this option's value. The source
(prefix) follows, padded out (zeroed) to 32 bits.
The following 8 bits represent the mask length ("masklen") to be 7.2.2. Sample Control Packets
applied to "source", which comprises the following 32-bits, padded
out (zeroed) to 32-bits if necessary.
"Group" is encoded exactly like "source", using an 8-bit masklen, This section shows some sample constructions of a selection of dif-
followed by a group prefix, padded out to 32 bits if necessary. ferent CBT control packet types.
This sequence is repeated "# (S,G)" times. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common
| 3 | 0 | 4 | Checksum | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
| 4 | 1 | reserved | Payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
| 1 | 1 | Preference | Padding | Option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
Figure 7. Sample HELLO packet
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common
| 3 | 1 | 4 | Checksum | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
| 16 | 0 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control
| Group Address | Packet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload
| Core Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Join-Originating DR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
Figure 8. Sample (*, G) JOIN_REQUEST (no options included)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common
| 3 | 2 | 4 | Checksum | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
| 12 | 0 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control
| Group Address | Packet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload
| Join Originating DR (copied from JOIN_REQUEST) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
Figure 9. Sample (*, G) JOIN_ACK (no options included)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common
| 3 | 1 | 4 | Checksum | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
| 16 | 1 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control
| Group Address | Packet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload
| Core Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Join-Originating DR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
| 5 | 5 | 24 | Src Addr Pfx..| Option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|.............. Src Addr Prefix .............. | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
Figure 10. Sample (S, G) JOIN_REQUEST
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common
| 3 | 4 | 4 | Checksum | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
| 8 + (n x 4) | 0 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control
| ECHO_REQUEST Originating Router | Packet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload
| Address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
Figure 11. Sample ECHO_REQUEST
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common
| 3 | 5 | 4 | Checksum | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
| 8 + (n x 4) | 0 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control
| ECHO_REPLY Originating Router | Packet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload
| Address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------
Figure 12. Sample ECHO_REPLY
8. Core Router Discovery 8. Core Router Discovery
There are two available options for CBTv2 core discovery; the "boot- There are two available options for CBTv2 core discovery; the "boot-
strap" mechanism (as currently specified with the PIM sparse mode strap" mechanism (as currently specified with the PIM sparse mode
protocol [2]) is applicable only to intra-domain core discovery, and protocol [2]) is applicable only to intra-domain core discovery, and
allows for a "plug & play" type operation with minimal configuration. allows for a "plug & play" type operation with minimal configuration.
The disadvantage of the bootstrap mechanism is that it is much more The disadvantage of the bootstrap mechanism is that it is much more
difficult to affect the shape, and thus optimality, of the resulting difficult to affect the shape, and thus optimality, of the resulting
distribution tree. Also, to be applicable, all CBT routers within a distribution tree. Also, to be applicable, all CBT routers within a
domain must implement the bootstrap mechanism. domain must implement the bootstrap mechanism.
The other option is to manually configure leaf routers with <core, The other option is to manually configure leaf routers with <core,
group> mappings (note: leaf routers only); this imposes a degree of group> mappings (note: leaf routers only); this imposes a degree of
administrative burden - the mapping for a particular group must be administrative burden - the mapping for a particular group must be
coordinated across all leaf routers to ensure consistency. Hence, coordinated across all leaf routers to ensure consistency. Hence,
this method does not scale particularly well. However, it is likely this method does not scale particularly well. However, it is likely
skipping to change at page 32, line 15 skipping to change at page 35, line 31
8.2. Bootstrap Message Format 8.2. Bootstrap Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT common control packet header | | CBT common control packet header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| For full Bootstrap Message specification, see [6] | | For full Bootstrap Message specification, see [6] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. Bootstrap Message Format Figure 13. Bootstrap Message Format
8.3. Candidate Core Advertisement Message Format 8.3. Candidate Core Advertisement Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT common control packet header | | CBT common control packet header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| For full Candidate Core Adv. Message specification, see [6] | | For full Candidate Core Adv. Message specification, see [6] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. Candidate Core Advertisement Message Format Figure 14. Candidate Core Advertisement Message Format
Acknowledgements Acknowledgements
Special thanks goes to Paul Francis, NTT Japan, for the original Special thanks goes to Paul Francis, NTT Japan, for the original
brainstorming sessions that brought about this work. brainstorming sessions that brought about this work.
The use of a single core model since CBTv2 owes much to Clay Shields The use of a single core model since CBTv2 owes much to Clay Shields
and his work on Ordered CBT (OCBT) [7]. Clay identified and proved and his work on Ordered CBT (OCBT) [7]. Clay identified and proved
several failure modes of CBT(v1) as it was specified with multiple several failure modes of CBT(v1) as it was specified with multiple
cores, and also suggested using an unreliable quit mechanism, which cores, and also suggested using an unreliable quit mechanism, which
has appeared since the CBTv2 specification as the QUIT_NOTIFICATION. has appeared since the CBTv2 specification as the QUIT_NOTIFICATION.
Clay also provided more general constructive comments on the CBT Clay also provided more general constructive comments on the CBT
architecture and specification. architecture and specification.
Others that have contributed to the progress of CBT include Ken Carl- Others that have contributed to the progress of CBT include Ken Carl-
berg, Eric Crawley, Jon Crowcroft, Bill Fenner, Mark Handley, Ahmed berg, Eric Crawley, Jon Crowcroft, Bill Fenner, Mark Handley, Ahmed
Helmy, Nitin Jain, Alan O'Neill, Steven Ostrowsksi, Radia Perlman, Helmy, Nitin Jain, Alan O'Neill, Steven Ostrowsksi, Radia Perlman,
Scott Reeve, Benny Rodrig, Martin Tatham, Dave Thaler, Sue Thompson, Scott Reeve, Benny Rodrig, Martin Tatham, Dave Thaler, Sue Thompson,
Paul White, and other participants of the IETF IDMR working group. Paul White, and other participants of the IETF IDMR working group.
Thanks also to 3Com Corporation and British Telecom Plc for assisting Thanks also to 3Com Corporation and British Telecom (BT) Plc for
with funding this work. assisting with funding this work.
Finally, thanks to Graeme Brown, BT Labs UK, for his ongoing imple-
mentation effort porting CBT to FreeBSD. For further information on
this implementation contact <graeme.brown@bt-sys.bt.co.uk>, Alan
O'Neill <alan.oneill@bt-sys.bt.co.uk>, or Tony Ballardie <ABal-
lardie@acm.org>.
References References
[1] Core Based Trees (CBT) Multicast Routing Architecture; A. Bal- [1] Core Based Trees (CBT) Multicast Routing Architecture; A. Bal-
lardie; RFC 2201; ftp://ds.internic.net/rfc/rfc2201.txt. lardie; RFC 2201; ftp://ds.internic.net/rfc/rfc2201.txt.
[2] Protocol Independent Multicast (PIM) Sparse Mode/Dense Mode; D. [2] Protocol Independent Multicast (PIM) Sparse Mode/Dense Mode; D.
Estrin et al; http://netweb.usc.edu/pim RFC XXXX and Working drafts. Estrin et al; http://netweb.usc.edu/pim RFC XXXX and Working drafts.
[3] Internet Group Management Protocol, version 2 (IGMPv2); W. Fenner; [3] Internet Group Management Protocol, version 2 (IGMPv2); W. Fenner;
skipping to change at page 34, line 20 skipping to change at page 38, line 20
e-mail: ABallardie@acm.org e-mail: ABallardie@acm.org
Brad Cain, Brad Cain,
Bay Networks Inc., Bay Networks Inc.,
3, Federal Street, 3, Federal Street,
Billerica, MA 01821, USA. Billerica, MA 01821, USA.
e-mail: bcain@baynetworks.com e-mail: bcain@baynetworks.com
voice: +1 978 916 1316 voice: +1 978 916 1316
Zhaohui "Jeffrey" Zhang, Zhaohui "Jeffrey" Zhang,
Bay Networks Inc., Argon Networks Inc.,
600 Technology Park Drive, 25, Porter Road,
Billerica, MA 01821, USA. Littleton, MA 01460, USA.
Phone: +1 (978) 439 0280 Phone: +1 (978) 392 4681
Fax: +1 978 670 8760 e-mail: zzhang@argon.com
e-mail: zzhang@baynetworks.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/