draft-ietf-mboned-sadp-00.txt   draft-ietf-mboned-sadp-01.txt 
Malloc Working Group Roger Kermode Mboned Working Group Roger Kermode
Internet Engineering Task Force Motorola Internet Engineering Task Force Motorola
INTERNET-DRAFT INTERNET-DRAFT Dave Thaler
8 November 1998 22 January 1999 Microsoft
Expires 8 May 1999 Expires 22 July 1999
Scoped Address Discovery Protocol (SADP) Scoped Address Discovery Protocol (SADP)
<draft-ietf-mboned-sadp-00.txt> <draft-ietf-mboned-sadp-01.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet-Draft and is in full conformance
documents of the Internet Engineering Task Force (IETF), its Areas, with all provisions of Section 10 of RFC2026.
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 Internet-Drafts are working documents of the Internet Engineering
updated, replaced, or obsoleted by other documents at any time. It Task Force (IETF), its areas, and its working groups. Note that
is inappropriate to use Internet Drafts as reference material or to other groups may also distribute working documents as
cite them other than as a "work in progress". Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines a protocol, the Scoped Address Discovery This document defines an application-layer protocol, the Scoped
Protocol (SADP), for discovering the scoped multicast address(es) Address Discovery Protocol (SADP), for discovering the scoped
associated with a session at particular scopes within a multicast address(es) associated with a session at particular scopes
hierarchically nested set of multicast zones. SADP is designed to within a hierarchically nested set of multicast scopes. SADP is
work within the context of Multicast Address Allocation Architecture designed to work within the context of Multicast Address Allocation
[MAAA] consisting of the MZAP [MZAP], MASC [MASC], and AAP [AAP] Architecture [MAAA]. It is intended that SADP will provide the
protocols. It is intended that SADP will provide the necessary necessary general services for reliable multicast and searching
general services for reliable multicast and searching applications to applications to use expanding-scope searches in lieu of the well
use expanding-zone searches in lieu of the well known, but less known, but less efficient expanding-ring search.
efficient expanding-ring search.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Contents Contents
Abstract. . . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract. . . . . . . . . . . . . . . . . . . . . . . . . 1
1. Introduction. . . . . . . . . . . . . . . . . . . . . 3 1. Introduction. . . . . . . . . . . . . . . . . . . . . 3
2. Overview. . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview. . . . . . . . . . . . . . . . . . . . . . . 4
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Session Identifiers . . . . . . . . . . . . . . . . 6 3.1 Session Identifiers . . . . . . . . . . . . . . . . 6
3.2 Session Member Operation. . . . . . . . . . . . . . 6 3.2 Session Member Operation. . . . . . . . . . . . . . 6
3.3 SADP Server Operation . . . . . . . . . . . . . . . 7 3.3 SADP Server Operation . . . . . . . . . . . . . . . 7
4. Packet Formats. . . . . . . . . . . . . . . . . . . . 8 4. Packet Formats. . . . . . . . . . . . . . . . . . . . 8
4.1 SADP Request. . . . . . . . . . . . . . . . . . . . 10 4.1 SADP Request. . . . . . . . . . . . . . . . . . . . 10
4.2 SADP Response . . . . . . . . . . . . . . . . . . . 10 4.2 SADP Response . . . . . . . . . . . . . . . . . . . 10
4.2 SADP New Address. . . . . . . . . . . . . . . . . . 11
5. Constants . . . . . . . . . . . . . . . . . . . . . . 11 5. Constants . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . 11
7. Acknowledgements. . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements. . . . . . . . . . . . . . . . . . . 11
8. References. . . . . . . . . . . . . . . . . . . . . . 12 8. References. . . . . . . . . . . . . . . . . . . . . . 11
9. Author's Address. . . . . . . . . . . . . . . . . . . 13 9. Author's Address. . . . . . . . . . . . . . . . . . . 12
10. Full Copyright Statement. . . . . . . . . . . . . . . 13 10. Full Copyright Statement. . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Administrative scoping [RFC2365] provide a useful means for limiting Administrative scoping [RFC2365] provides a useful means for limiting
the spread of IP multicast traffic acros the Internet. Unlike Time- the spread of IP multicast traffic across the Internet. Unlike Time-
To-Live (TTL) scoping, administrative scoping provides the means to To-Live (TTL) scoping, administrative scoping provides the means to
ensure that, for a given scope and ignoring packet loss, the same set ensure that, for a given scope and ignoring packet loss, the same set
of nodes will receive a message, regardless of which node sent the of nodes will receive a message, regardless of which node sent the
message. Thus, the use of administrative scoping greatly simplifies message. Thus, the use of administrative scoping greatly simplifies
the design of multicast protocols that require localization, since the design of multicast protocols that require localization, since
the non-reception of sent packets is solely due to loss and not the non-reception of sent packets is solely due to loss and not
design. design.
The Multicast Zone Announcement Protocol (MZAP) [MZAP] will provide The Multicast Address Dynamic Client Allocation Protocol (MADCAP)
applications with the means for discovering the various scopes that [MADCAP] will provide applications with the means for discovering the
are locally visible at each point in the Internet. In addition, MZAP various scopes that are locally visible at each point in the
will also provide the means for determining and announcing which Internet. The determination of which scopes nest inside each other
scope zones completely encapsulate others. This additional ability will be performed by the Multicast-Scope Zone Announcement Protocol
will allow scope zones to be arranged into hierarchies which (MZAP) [MZAP]. MZAP's ability to provide this service will allow
applications can then used expanding zone searches instead of less scopes to be arranged into hierarchies so that applications can then
efficient and more problematic expanding-ring (TTL) searches. One use expanding scope searches instead of the less efficient and more
example of how expanding-zone searches provide increased localization problematic expanding-ring (TTL) searches. One example of how
can be found in the Scoped Hybrid Automatic Repear reQuest with expanding-scope searches provide increased localization can be found
Forward Error Correction (SHARQFEC) reliable multicast protocol in the Scoped Hybrid Automatic Repeat reQuest with Forward Error
[SHARQFEC]. Correction (SHARQFEC) reliable multicast protocol [SHARQFEC].
While expanding-ring searches use one multicast address and While expanding-ring searches use one multicast address and
increasing TTLs, expanding-zone searches involve changing the increasing TTLs, expanding-scope searches involve changing the
multicast addresses for each attempt at a different scope. SADP multicast addresses for each attempt at a different scope. For well-
builds upon the Multicast Address Allocation Architecture [MAAA] by known services, these addresses can be obtained by applying an IANA-
adding a new service that allows applications to discover the assigned offset from the top of the scope's address range.
relevant multicast address(es) associated with a session at each Applications, on the other hand, generally require the use of
level in a hierarchy of scope zones. SADP does not provide the means dynamically allocated addresses with offsets that will most likely
to allocate an address should one not be present for a session in a vary from scope to scope.
particular zone. In this case the application should use the Address
Allocation Protocol (AAP) [AAP] to allocate a new address for the SADP builds upon the Multicast Address Allocation Architecture [MAAA]
scope, which can then be announced to other application instances by adding a new application-layer service that allows applications to
within the scope. discover the relevant multicast address(es) associated with a session
at each level in a hierarchy of scopes.
SADP does not provide the means to allocate an address should one not
be present for a session in a particular zone. In this case the
application should take steps to obtain an address for that scope and
then announce it to other application instances that join that scope
at a later time. One proposed mechanism for allocating addresses is
the Multicast Address Dynamic Allocation Protocol (MADCAP) [MADCAP].
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Overview 2. Overview
Administrative scoping affords the ability to create network Administrative scoping affords the ability to create network
partitions or zones in which multicast traffic addressed to one of a partitions or zones in which multicast traffic addressed to one of a
block of addresses assigned to that zone will be limited to that block of addresses assigned to that zone will be limited to that
zone. The boundary of the zone is enforced by Zone Border Routers zone. The boundary of the zone is enforced by Zone Border Routers
(ZBRs) that reside at the edges of the zone. ZBRs must be carefully (ZBRs) that reside at the edges of the zone. ZBRs must be carefully
configured so that traffic addressed within the zone does not pass configured so that traffic addressed within the zone does not pass
outside the zone. This can be a non trivial task, and hence the outside the zone. Ensuring consistency among boundary routers can be
Multicast Zone Announcement Protocol (MZAP) [MZAP], which is used to a non-trivial task, and hence the Multicast Zone Announcement
announce the existence of zones, also provides the mechanisms to Protocol (MZAP) [MZAP], which is used to announce the existence of
detect ZBR misconfigurations. zones, also provides the mechanisms to detect ZBR misconfigurations.
. . . . . . . . . +B+------> . . . . . . . . . +B+------>
. . / . . /
. * . *
. <---+A*--------+C+---> . <---+A*--------+C+--->
. + . . + .
. / . . / .
. Zone X <--- . . Zone X <--- .
. . . . . . ... . . . . . . ...
skipping to change at page 4, line 42 skipping to change at page 4, line 46
the services of zone announcement and fault detection, MZAP also the services of zone announcement and fault detection, MZAP also
provides mechanisms for determining and announcing the existence of provides mechanisms for determining and announcing the existence of
zones that nest inside others as shown in Figure 2. zones that nest inside others as shown in Figure 2.
+-----------+ +-----------+ +-------------+ +-----------+ +-----------+ +-------------+
| zone a | | zone c | | zone e | | zone a | | zone c | | zone e |
| +------+| | +------+ | . . . . .|.. | +------+| | +------+ | . . . . .|..
| |zone b|| | |zone d| | : zone f | : | |zone b|| | |zone d| | : zone f | :
| +------+| | | | | : | : | +------+| | | | | : | :
+-----------+ +----+------+ +-------------+ : +-----------+ +----+------+ +-------------+ :
:. . . . ..: : . . . . . :
(a) "Contained" (b) "Common Border" (c) "Overlap" (a) "Contained" (b) "Common Border" (c) "Overlap"
zone b nests zone d nests zones e and f zone b nests zone d nests zones e and f
inside zone a inside zone c do not nest inside zone a inside zone c do not nest
Figure 2: Zone nesting examples Figure 2: Zone nesting examples
This feature allows admin scope zones to be arranged in a hierarchy This feature allows admin scope zones to be arranged in a hierarchy
as shown in Figure 3. The ability to nest admin scope zones in as shown in Figure 3. The ability to nest admin scope zones in
hierarchies like that shown in Figure 3 is useful since it affords hierarchies like that shown in Figure 3 is useful since it affords
localization through expanding-zone searches. For example, consider a localization through expanding-scope searches. For example, consider
distributed application with session members distributed evenly a distributed application with session members distributed evenly
through out zone a. A session member in zone e, would perform a through out zone a. A session member in scope e, would perform a
search by multicasting a query within zone e, and if unsuccessful, search by multicasting a query within scope e, and if unsuccessful,
expand the scope to search in zone b, and eventually zone a if so expand the scope to search in scope b, and eventually scope a if so
needed. needed.
. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . ..
. zone a . Zone Boundaries . scope a . Scope Boundaries
. . . = zone a . . . = scope a
. ______________ ______________ . - = zones b,c . _______________ ________________ . - = scopes b,c
. / zone b \ / zone c \ . # = zones d,e,f, & g . / scope b \ / scope c \ . # = scopes d,e,f, & g
.| | | |. .| | | |.
.| #### #### | | #### #### |. .| ##### ##### | | ##### ##### |.
.| #zone# #zone# | | #zone# #zone# |. .| #scope# #scope#| | #scope# #scope# |.
.\ # d # # e # | | # f # # g # /. .\ # d # # e # | | # f # # g # /.
.\ ### #### / \ #### #### /. .\ #### #####/ #### #### /.
.\___________/ \____________/. .\____________/ _____________/.
. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .
Figure 3 : Zone Nesting Hierarchy example Figure 3 : Admin Scope Zone Nesting Hierarchy example
In order for expanding-zone searches to be feasible, session members In order for expanding-scope searches to be feasible, session members
must be able to determine two things: must be able to determine two things:
o which zones are involved in the hierarchy for a particular session. o which scopes are involved in the hierarchy for a particular
session.
o what address(es) are to be used for communicating with other o what address(es) are to be used for communicating with other
session members within the zones involved in the hierarchy. session members within these scopes.
SADP affords the ability to discover this information by using a SADP affords the ability to discover this information by using a
single multicast group at each scope [SADP-RELATIVE-GROUP] for single multicast group inside each scope [SADP-RELATIVE-GROUP] for
communication between SADP servers and the members of various communication between SADP servers (see section 3.2) and the members
sessions. New members to a session use the channels provided by the of various sessions. New members to a session use the channels
addresses to query existing SADP servers and session members as to provided by the addresses to query existing SADP servers and session
which specific zones are valid and which zones to use. Since there is members as to which specific scopes are valid and which scopes to
only one multicast address used per zone for this purpose, members of use. Since there is only one multicast address used per admin scope
a particular session will ignore traffic intended for members of zone for this purpose, members of a particular session will ignore
another session. traffic intended for members of another session.
3. Usage 3. Usage
In this section we summarize how session members can use SADP to In this section we summarize how session members can use SADP to
determine which admin zones are used by the session's hierarchy and determine which admin zones are used by the session's hierarchy and
also the address(es) within these zones that are used by the current also the address(es) within these zones that are used by the current
session members should such addresses exist. session members should such addresses exist.
3.1 Session Identifiers 3.1 Session Identifiers
Each session that uses admin scoping will use a Globally Unique Each session that uses administrative scoping will be identified by a
Session Identifier (GUSID) that will distinguish it from all other Session Identifier (SID) that corresponds to the address of the group
sessions. This GUSID will consists of a 128bit integer that is used in the largest scope zone. Applications that require multiple
allocated dynamically using the process described in [UUID]. The addresses shall be decomposed into multiple individual sessions which
GUSID will be allocated by the session creator and will be used to will then be treated independently.
associate traffic with a particular session regardless of which
multicast scoped address the traffic is sent to.
3.2 Session Member Operation 3.2 Session Member Operation
Several predefined administrative scopes already exist [RFC2365]: Several predefined administrative scopes already exist [RFC2365]:
o Link Local: Traffic is only carried across one physical link. o Link Local: Traffic is only carried across one physical link.
o Local: Traffic is restricted to a specific network region. o Local: Traffic is restricted to a specific network region.
o Global: The entire multicast enabled network. o Global: The entire multicast enabled network.
By definition Link Local zones nest inside Local zone which in turn By definition Link Local scopes nest inside Local scopes which in
nests inside the Global zone. Other zones may exist between the local turn nest inside the Global Scope. Other scopes may exist between the
and global scopes. These zones are constructed by the union of two or local and global scopes. These scopes are constructed by the union of
more local zones and are announced to routers within their confines the admin scope zones that correspond to two or more topologically
using MZAP [MZAP]. adjacent local scopes and are announced to routers within their
confines using MZAP [MZAP].
The general algorithm that new members to a session should use to The general algorithm that new members to a session should use to
determine which zones and addresses are involved in the hierarchy for determine which scopes and addresses are involved in the hierarchy
a particular session is as follows: for a particular session is as follows:
1) Determine the GUSID, largest zone, and addresses for the largest 1) Determine largest scope, and address for the largest scope for
zone for the session. (this task is beyond the scope of this the session. (this task is beyond the scope of this document,
document, but can be assumed to involve some kind of out-of-band but can be assumed to involve some kind of out-of-band
communication.) communication.)
2) Starting with the SADP group [SADP-RELATIVE-GROUP] for the 2) Starting with the SADP group [SADP-RELATIVE-GROUP] for the
local scope, issue a SADP Request (SADP_REQ) message local scope, issue a SADP Request (SADP_REQ) message
containing the GUSID address. containing the SID address.
3) Wait for a response on the SADP [SADP-RELATIVE-GROUP] address 3) Wait for a response on the SADP [SADP-RELATIVE-GROUP] address
for at least [SADP-REQ-TIMEOUT] seconds. If no response is for at least [SADP-REQ-TIMEOUT] seconds. If no response is
heard increase the scope to the next largest zone and repeat step heard, wait for some small amount of time, and then
2. In cases where there are two non-nesting zones larger than the repeat the request at the same scope.
current try one zone and then the other, should the first zone not
result in a reply.
4) Continue steps 2) and 3) until the largest zone has been queried 4) If after a total of 3 attempts at a given scope, no response
or a response has been heard. has been received, increase the scope to the next largest scope
and repeat steps 2 and 3. In cases where there are two
non-nesting scopes larger than the current, try one scope and
then the other, should the first scope not result in a reply.
5) Continue steps 2), 3), and 4) until the largest scope has been
queried or a response has been heard.
In cases where the scope must be increased in order to find a session In cases where the scope must be increased in order to find a session
member that can reply, the new session member MAY decide to add member that can reply, the new session member MAY decide to add
levels to the hierarchy in order to increase localization for future levels to the hierarchy in order to increase localization for future
session members. New session members that decide to take this step session members. New session members that decide to take this step
will use the existing addresses as discovered using SADP and request will use the existing addresses as discovered using SADP and request
new ones using AAP [AAP]. new ones. (e.g., via MADCAP [MADCAP]). Upon the successful
allocation of a new address for use in the hierarchy, the new session
member shall announce the new address via a SADP_NEW_ADDR message to
the [SADP-RELATIVE-GROUP] address for the scope in which the address
was allocated. This will cause the address to be cached by any SADP
servers within the new address's scope.
SADP servers and existing session members, upon hearing an SADP_REQ SADP servers and existing session members, upon hearing an SADP_REQ
message from a new session member will issue an SADP Response message from a new session member from [SADP-RELATIVE-GROUP] at a
(SADP_RESP) after waiting for a random amount of time (T) that is particular scope will issue an SADP Response (SADP_RESP) to the
calculated as follows: [SADP-RELATIVE-GROUP] at the same scope after waiting for a random
amount of time (T) that is calculated as follows:
Choose a random value X from a uniform random interval [0:1] Choose a random value X from a uniform random interval [0:1] Let
Let C = 256 C = 256 Set
Set T = [SADP-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C) T = [SADP-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)
Should a member receive a SADP_RESP before its timer it expires it Should a member receive a SADP_RESP before its timer it expires it
SHALL suppress its own response. This method ensures that close to SHALL suppress its own response. This method ensures that close to
one session member will respond. one session member will respond.
3.2 SADP Server Operation 3.3 SADP Server Operation
Were SADP to be deployed in a wide scale session with the members of Were SADP to be deployed in a wide scale session with the members of
various sessions to use SADP between each other it would quickly various sessions to use SADP between each other it would quickly
cause catastrophic congestion. The reason for this is that whenever a cause catastrophic congestion. The reason for this is that whenever a
new node joined a sparsely populated session with a large maximum new node joined a sparsely populated session with a large maximum
scope, it would inevitably end up sending SADP_REQs to every scope up scope, it would inevitably end up sending SADP_REQs to every scope up
until the largest scope. Thus the highly likely occurrence of having until the largest scope. Thus the highly likely occurrence of having
a global and continental scope zones combined with numerous sparse a global and continental scopes combined with numerous sparse
sessions (probably on the order of 10,000 to 100,000) would quickly sessions (probably on the order of 10,000 to 100,000) would quickly
cause SADP_REQ flooding at the continental scope. cause SADP_REQ flooding at the continental scope.
To address this shortcoming SADP allows, and in fact encourages, the To address this shortcoming SADP allows, and in fact encourages, the
deployment of SADP servers. These servers subscribe to the [SADP- deployment of SADP servers. These servers subscribe to the [SADP-
RELATIVE-GROUP] for each zone they are in and cache the SADP_RESP RELATIVE-GROUP] for each scope they are in and cache the SADP_RESP
messages they receive at each scope. Having cached and merged the messages they receive at each scope. Having cached and merged the
responses for sessions at various scopes, they can then respond to responses for sessions at various scopes, they can then respond to
SADP_REQs heard at lower scopes using the information heard at the SADP_REQs heard at lower scopes using the information heard at the
larger scope(s). Should a SADP server hear a SADP_REQ at some larger scope(s). Should a SADP server hear a SADP_REQ at some
intermediate scope it MUST NOT announce address information for intermediate scope it MUST NOT announce address information for
scopes smaller than one on which the SADP_REQ was received. scopes smaller than one on which the SADP_REQ was received.
The effect of allowing larger-scoped information to be announced at The effect of allowing larger-scoped information to be announced at
lower scopes by SADP servers significantly reduces the number of lower scopes by SADP servers significantly reduces the number of
scopes a new session will have to query. New session members now need scopes a new session will have to query. New session members now need
skipping to change at page 8, line 14 skipping to change at page 8, line 34
Scope b Boundary Scope b Boundary
Scope a : Scope a and Scope b Scope a : Scope a and Scope b
_________ : ____________ _____________ _________ : ____________ _____________
/ \ : / \ / \ / \ : / \ / \
|Source at| _____:___\ |SADP Server | /___________ | New Session | |Source at| _____:___\ |SADP Server | /___________ | New Session |
|Scope a | SADP_RESP/ | Scopes a,b | \ SADP_REQ | Member | |Scope a | SADP_RESP/ | Scopes a,b | \ SADP_REQ | Member |
\_________/ : \____________/ ___________\ | Scopes a,b | \_________/ : \____________/ ___________\ | Scopes a,b |
: SADP_RESP/ \_____________/ : SADP_RESP/ \_____________/
: :
Figure 4 : SADP Server acting as proxy session member Figure 4 : SADP Server acting as proxy session member
4. Packet Formats 4. Packet Formats
All SADP messages are sent over UDP, with a destination port of All SADP messages are sent over UDP, with a destination port of
[SADP-PORT]. THe common SADP message header (which follows the UDP [SADP-PORT]. The common SADP message header (which follows the UDP
header), is shown below, header), is shown below,
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | PTYPE |NumScop|AddrFam| NameLen | | Version | PTYPE | Num Scopes | Addr Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Origin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (Hi) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (Mid Hi) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (Mid Lo) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (Lo) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Name | | Largest Scope Group Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Block Authentication Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 8 bits Version: 8 bits
The version defined in this document is version 0. The version defined in this document is version 0.
Packet Type (PTYPE): 8 bits Packet Type (PTYPE): 8 bits
The packet types defined in this document are: The packet types defined in this document are:
0: SADP Request 0: SADP Request
1: SADP Response 1: SADP Response
Number of Scope Entries (NumScop) : 4 bits 2: SADP New Address
The number of scope entries present within a SADP_RESP message.
This field should be set to zero for SADP_REQ messages.
Address Family (AddrFam): 4 bits
This indicates the format of the following packet. The following
values are defined by this document:
0: IPv4
1: IPv6
Message Origin: 32 bits (IPv4) or 128 bits (IPv6)
This gives the IP address of the interface that originated the
message.
Session ID Address: 128 bits
This 128 bit number uniquely identifies a session.
Name Len: Number of Scope Entries (Num Scopes) : 4 bits
The length, in bytes, of the Session Name field. The number of scope entries present within a SADP_RESP
message. This field should be set to zero for SADP_REQ messages.
Session Name: multiple of 8 bits Address Family (AddrFam): 4 bits
The Zone Name is an ISO 10646 character string in UTF-8 encoding This indicates the IANA-assigned address family number to be
[RFC2279] indicating the name given to the session (e.g.: used for address contained in this message. Currently assigned
``42ndIETF-Chicago''). It should be relatively short and MUST be values are listed in RFC 1700 [RFC1700]. The values for IP
less than 256 bytes in length. All the session members SHOULD be addresses are:
configured to give the same Session Name, or a zero length string IPv4: 1
MAY be given. A zero length string is taken to mean that another IPv6: 2
session member is expected to be configured with the session
name. Having ALL the members of a session announce zero length
names should be considered an error.
Padding (if needed): Session ID Address: 32 bits (IPv4) or 128 bits (IPv6)
The SADP header is padded with null bytes until it is 4-byte The group address corresponding to the largest scope for this
aligned. hierarchy of addresses.
Authentication Block: Authentication Block:
The Authentication Block provides information which can be used The Authentication Block provides information which can be used
to confirm that the sender of the SADP message is a valid member to confirm that the sender of the SADP message is a valid member
of the session. Session Members that cannot confirm that the of the session. Session Members that cannot confirm that the
sender of an SADP Request Message MAY ignore it, while new sender of an SADP Request Message MAY ignore it, while new
session members that receiver an SADP Response Message MUST session members that receive an SADP Response Message MUST
ignore it. (the format of the authentication block is to be ignore it. (The format of the authentication block is to be
decided) decided)
4.1 SADP Request 4.1 SADP Request
SADP Request (SADP_REQ) Messages have PTYPE=0, and are sent by new SADP Request (SADP_REQ) Messages have PTYPE=0, and are sent by new
session members that wish to learn which administrative scopes and session members that wish to learn which administrative scopes and
multicast addresses to use within a particular session. SADP_REQ multicast addresses to use within a particular session. SADP_REQ
Messages are sent according to the algorithm described in 3.2. Messages are sent according to the algorithm described in 3.2.
4.2 SADP Response 4.2 SADP Response
The SADP Response (SADP_RESP) Message has PTYPE=1, and is sent in The SADP Response (SADP_RESP) Message has PTYPE=1, and is sent in
response to a SADP_REQ Message. It contains the list of address that response to a SADP_REQ Message to the same scope from which the
are to be used by a session within each scope. Session members that SADP_REQ was received. It contains the address that is to be used by
transmit SADP Response Messages MUST NOT include zone and address an application instance within a session for each scope that nests
information for scopes known to be smaller that of the address upon within the scope to which the SADP_REQ was sent. (N.B. This includes
which the triggering SADP Request Message was received. the scope to which the SADP_REQ was sent) Session members that
transmit SADP Response Messages MUST NOT include scope and address
information for scopes that are known to overlap or be larger than
that of the scope upon which the triggering SADP_REQ Message was
The format for a SADP Response Message is shown below: The format for a SADP Response Message is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MSADP Header SADP Header
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| MBZ | SCOP | NumSessAddr | MBZ | | Scope Start Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Start Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Stop Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone 1 Session Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone 1 Session Address K | | Scope 1 Session Address |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| MBZ | SCOP | NumSessAddr | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Start Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone Stop Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone N Session Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . . . . . . . . . . .
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Scope Start Address N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone N Session Address L | | Scope N Session Address |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
SCOP : 4 bits
The SCOP value associated with the zone as defined in RFC 1884
[RFC1884] for IPv6 and RFC 2365 [RFC2365] for IPv4.
NumSessAddr : 8 bits
The number of session address per scope zone that are included.
Addresses will be listed in ascending order. The correspondence
between address and channel function is the responsibility of
the session application.
MBZ :
Must Be Zero, these bits must be set to zero, but may be used
for other functions later revision of the protocol.
Zone X Start Address : 32 bits (IPv4) or 128 bits (IPv6) Scope X Start Address : 32 bits (IPv4) or 128 bits (IPv6)
The smallest address for the block of multicast addresses The smallest address for the block of multicast addresses
associated with a zone. If a zone X is valid for the range associated with a scope. If a scope X is valid for the range
239.128.0.0 to 239.128.255.255, this field will be set to 239.128.0.0 to 239.128.255.255, this field will be set to
239.128.0.0. 239.128.0.0.
Zone X Stop Address : 32 bits (IPv4) or 128 bits (IPv6) Scope X Session Address : 32 bits (IPv4) or 128 bits (IPv6)
The largest address for the block of multicast addresses Address to be used for the named scope.
associated with a zone. If a zone X is valid for the range
4.2 SADP New Address
The SADP New Address (SADP_NEW_ADDR) Message has PTYPE=2. It is
transmitted by session members that have attempted to find an address
for a particular scope, failed, and have then subsequently allocated
a new address for use in the session at that scope. Its purpose is
to inform other members of the session of the existence of this newly
allocated address and its availability for subsequent use.
Should two members attempt to announce a new address to the same
scope at the same time, their SADP_NEW_ADDR messages will result in a
collision. SADP_NEW_ADDR collisions are resolved by the session
members picking the lower of the two addresses.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SADP Header
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Scope Start Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Scope Session Address |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Scope Start Address : 32 bits (IPv4) or 128 bits (IPv6)
The smallest address for the block of multicast addresses
associated with a scope. If a scope X is valid for the range
239.128.0.0 to 239.128.255.255, this field will be set to 239.128.0.0 to 239.128.255.255, this field will be set to
239.128.255.255. 239.128.0.0.
Zone X Session Address Y : 32 bits (IPv4) or 128 bits (IPv6) New Scope Session Address : 32 bits (IPv4) or 128 bits (IPv6)
Up to Y address may be included for a zone address entry, where Address of the newly allocated group to be used for the
Y is equal to the NumSessAddr value for entry X. specified scope.
5. Constants 5. Constants
[SADP-RELATIVE-GROUP]: The relative group with each scope zone, to [SADP-RELATIVE-GROUP]: The relative group with each scope, to which
which session members send SADP Requests and Responses. All sessions session members send SADP Requests and Responses. All application
that use administratively scoped multicast MUST subscribe to this instances that use SADP for constructing hierarchies of scopes MUST
address. subscribe to this address for each scope which nests within the
session scope, in order to ensure that each application instance uses
the hierarchy in the most efficient manner.
[SADP-REQ-TIMEOUT]: The time after which a session member that sends [SADP-REQ-TIMEOUT]: The time after which a session member that sends
SADP Request should wait before concluding that no session members SADP Request should wait before concluding that no session members
are present at the current scope. Default value is 3 seconds. are present at the current scope. Default value is 3 seconds.
[SADP-SUPPRESSION-INTERVAL]: The interval over which a session member [SADP-SUPPRESSION-INTERVAL]: The interval over which a session member
chooses a random delay before responding to SADP Request. Default chooses a random delay before responding to SADP Request. Default
value 2 seconds. value 2 seconds.
6. Security Considerations 6. Security Considerations
SADP employs distributed mechanisms to allow new session members to SADP employs distributed mechanisms to allow new session members to
learn of the existence of session-specific admin scoped multicast learn of the existence of session-specific admin scoped multicast
address. This fact lay SADP open to attack by malicious hosts that address. This fact lays SADP open to attack by malicious hosts that
could potentially mis-inform new session members of incorrect could potentially mis-inform new session members of incorrect
addresses, thereby affecting a man-in-the-middle attack. addresses, thereby affecting a man-in-the-middle attack.
To prevent attacks of this nature by non-session members from To prevent attacks of this nature by non-session members from
occurring all SADP messages are signed by the sender. However, this occurring all SADP messages are signed by the sender. However, this
measure does not prevent malicious hosts from joining a session and measure does not prevent malicious hosts from joining a session and
then performing the same attack. Hence, SADP's security depends upon then performing the same attack. Hence, SADP's security depends upon
a suitable gating process for new-member admittance combined with (as a suitable gating process for new-member admittance combined with (as
yet to be determined) mechanisms that allow spoofed SADP messages to yet to be determined) mechanisms that allow spoofed SADP messages to
be identified for removal before processing. be identified for removal before processing.
7. Acknowledgments 7. Acknowledgments
The Author would like to acknowledge Mark Handley and Dave Thaler for The Authors would like to acknowledge Mark Handley for the helpful
the helpful discussions and feedback which helped shape and refine discussions and feedback which helped shape and refine this document.
this document.
8. References 8. References
[AAP] Handley, M., "The Address Allocation Protocol", Internet [MADCAP] Patel. B.V., Shah, M., Hanna, S.R., "Multicast Address
Draft, August 1998. Dynamic Client Allocation Protocol (MADCAP)", Internet
Draft, draft-ietf-malloc-madcap-03.txt, February 1999.
[MAAA] Handley, M., Thaler, D., and D. Estrin, "The Internet [MAAA] Handley, M., Thaler, D., and D. Estrin, "The Internet
Multicast Address Allocation Architecture", Internet Multicast Address Allocation Architecture", Internet
Draft, December 1997. Draft, December 1997.
[MZAP] Handley, M., Thaler, D., "Multicast-Scope Zone [MZAP] Handley, M., Thaler, D., "Multicast-Scope Zone
Announcement Protocol (MZAP)", Announcement Protocol (MZAP)",
draft-ietf-mboned-mzap-02.txt, Internet-Draft, August, draft-ietf-mboned-mzap-02.txt, Internet-Draft, August,
1998. 1998.
[RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700,
October 1994.
[RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing [RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 1884, December 1995. Architecture", RFC 1884, December 1995.
[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, RFC 2119, March 1997. Requirement Levels", BCP, RFC 2119, March 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP, [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP,
RFC 2365, July 1998. RFC 2365, July 1998.
[SHARQFEC] Kermode, R., "Scoped Hybrid Automatic Repeat reQuest with [SHARQFEC] Kermode, R., "Scoped Hybrid Automatic Repeat reQuest with
Forward Error Correction (SHARQFEC)", ACM SIGCOMM98, Forward Error Correction (SHARQFEC)", ACM SIGCOMM98,
Vancouver Canada, September 1998. Vancouver Canada, September 1998.
[UUID] Leach, J., Salz, R., "UUIDs and GUIDs", 9. Authors' Addresses
draft-leach-uuids-guids-01.txt, Internet-Draft, February,
1998.
9. Author's Address
Roger Kermode Roger Kermode
Motorola Motorola Australia Research Centre
Chicago Corporate Research Laboratories 12 Lord St.
1301 East Algonquiin Rd, MS IL02-2712 Botany, NSW 2091
Schaumburg, IL 60196 Australia
Email: Roger_Kermode@email.mot.com
Phone: (847) 538 4587 David Thaler
Email: ark008@email.mot.com Microsoft
One Microsoft Way
Redmond, WA 98052
USA
Email: dthaler@microsoft.com
10. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it
assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing Internet organizations, except as needed for the purpose of
Internet standards in which case the procedures for copyrights defined developing Internet standards in which case the procedures for
in the Internet languages other than English. copyrights defined in the Internet languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
 End of changes. 

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