--- 1/draft-ietf-mboned-sadp-01.txt 2006-02-05 00:20:57.000000000 +0100 +++ 2/draft-ietf-mboned-sadp-02.txt 2006-02-05 00:20:57.000000000 +0100 @@ -1,146 +1,149 @@ - Mboned Working Group Roger Kermode Internet Engineering Task Force Motorola INTERNET-DRAFT Dave Thaler -22 January 1999 Microsoft -Expires 22 July 1999 +5 September 2000 Microsoft +Expires 5 March 2001 Scoped Address Discovery Protocol (SADP) - + Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are 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 + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines an application-layer protocol, the Scoped Address Discovery Protocol (SADP), for discovering the scoped multicast address(es) associated with a session at particular scopes within a hierarchically nested set of multicast scopes. SADP is designed to work within the context of Multicast Address Allocation Architecture [MAAA]. It is intended that SADP will provide the necessary general services for reliable multicast and searching applications to use expanding-scope searches in lieu of the well known, but less efficient expanding-ring search. Copyright Notice - Copyright (C) The Internet Society (1999). All Rights Reserved. + Copyright (C) The Internet Society (2000). All Rights Reserved. Contents Abstract. . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction. . . . . . . . . . . . . . . . . . . . . 3 2. Overview. . . . . . . . . . . . . . . . . . . . . . . 4 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Session Identifiers . . . . . . . . . . . . . . . . 6 3.2 Session Member Operation. . . . . . . . . . . . . . 6 3.3 SADP Server Operation . . . . . . . . . . . . . . . 7 4. Packet Formats. . . . . . . . . . . . . . . . . . . . 8 4.1 SADP Request. . . . . . . . . . . . . . . . . . . . 10 4.2 SADP Response . . . . . . . . . . . . . . . . . . . 10 - 4.2 SADP New Address. . . . . . . . . . . . . . . . . . 11 + 4.3 SADP New Address. . . . . . . . . . . . . . . . . . 11 5. Constants . . . . . . . . . . . . . . . . . . . . . . 11 - 6. Security Considerations . . . . . . . . . . . . . . . 11 + 6. Security Considerations . . . . . . . . . . . . . . . 12 - 7. Acknowledgements. . . . . . . . . . . . . . . . . . . 11 + 7. Acknowledgements. . . . . . . . . . . . . . . . . . . 12 - 8. References. . . . . . . . . . . . . . . . . . . . . . 11 + 8. References. . . . . . . . . . . . . . . . . . . . . . 12 - 9. Author's Address. . . . . . . . . . . . . . . . . . . 12 + 9. Author's Address. . . . . . . . . . . . . . . . . . . 13 - 10. Full Copyright Statement. . . . . . . . . . . . . . . 12 + 10. Full Copyright Statement. . . . . . . . . . . . . . . 14 1. Introduction Administrative scoping [RFC2365] provides a useful means for limiting the spread of IP multicast traffic across the Internet. Unlike Time- To-Live (TTL) scoping, administrative scoping provides the means to 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 message. Thus, the use of administrative scoping greatly simplifies the design of multicast protocols that require localization, since the non-reception of sent packets is solely due to loss and not design. The Multicast Address Dynamic Client Allocation Protocol (MADCAP) - [MADCAP] will provide applications with the means for discovering the - various scopes that are locally visible at each point in the - Internet. The determination of which scopes nest inside each other - will be performed by the Multicast-Scope Zone Announcement Protocol - (MZAP) [MZAP]. MZAP's ability to provide this service will allow - scopes to be arranged into hierarchies so that applications can then - use expanding scope searches instead of the less efficient and more - problematic expanding-ring (TTL) searches. One example of how - expanding-scope searches provide increased localization can be found - in the Scoped Hybrid Automatic Repeat reQuest with Forward Error - Correction (SHARQFEC) reliable multicast protocol [SHARQFEC]. + [RFC2730, NESTOPT] will provide applications with the means for + discovering the various scopes that are locally visible at each point + in the Internet. The determination of which scopes nest inside each + other will be performed by the Multicast-Scope Zone Announcement + Protocol (MZAP) [RFC2776]. MZAP's ability to provide this service + will allow scopes to be arranged into hierarchies so that + applications can then use expanding scope searches instead of the + less efficient and more problematic expanding-ring (TTL) searches. + One example of how expanding-scope searches provide increased + localization can be found in the Scoped Hybrid Automatic Repeat + reQuest with Forward Error Correction (SHARQFEC) reliable multicast + protocol [SHARQFEC]. While expanding-ring searches use one multicast address and increasing TTLs, expanding-scope searches involve changing the multicast addresses for each attempt at a different scope. For well- known services, these addresses can be obtained by applying an IANA- assigned offset from the top of the scope's address range. Applications, on the other hand, generally require the use of dynamically allocated addresses with offsets that will most likely vary from scope to scope. SADP builds upon the Multicast Address Allocation Architecture [MAAA] by adding a new application-layer service that allows applications to 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 Multicast Address Dynamic Allocation Protocol (MADCAP) [RFC2730]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Overview Administrative scoping affords the ability to create network partitions or zones in which multicast traffic addressed to one of a block of addresses assigned to that zone will be limited to that 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 configured so that traffic addressed within the zone does not pass outside the zone. Ensuring consistency among boundary routers can be a non-trivial task, and hence the Multicast Zone Announcement - Protocol (MZAP) [MZAP], which is used to announce the existence of + Protocol (MZAP) [RFC2776], which is used to announce the existence of zones, also provides the mechanisms to detect ZBR misconfigurations. . . . . . . . . . +B+------> . . / . * . <---+A*--------+C+---> . + . . / . . Zone X <--- . . . . . . . ... @@ -234,66 +237,66 @@ o Local: Traffic is restricted to a specific network region. o Global: The entire multicast enabled network. By definition Link Local scopes nest inside Local scopes which in turn nest inside the Global Scope. Other scopes may exist between the local and global scopes. These scopes are constructed by the union of the admin scope zones that correspond to two or more topologically adjacent local scopes and are announced to routers within their - confines using MZAP [MZAP]. + confines using MZAP [RFC2776]. The general algorithm that new members to a session should use to determine which scopes and addresses are involved in the hierarchy for a particular session is as follows: 1) Determine largest scope, and address for the largest scope for the session. (this task is beyond the scope of this document, but can be assumed to involve some kind of out-of-band communication.) 2) Starting with the SADP group [SADP-RELATIVE-GROUP] for the local scope, issue a SADP Request (SADP_REQ) message containing the SID address. 3) Wait for a response on the SADP [SADP-RELATIVE-GROUP] address for at least [SADP-REQ-TIMEOUT] seconds. If no response is heard, wait for some small amount of time, and then repeat the request at the same scope. - 4) If after a total of 3 attempts at a given scope, no response + 4) If after a total of 2 attempts at a given scope, no response 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 member that can reply, the new session member MAY decide to add levels to the hierarchy in order to increase localization for future session members. New session members that decide to take this step will use the existing addresses as discovered using SADP and request - new ones. (e.g., via MADCAP [MADCAP]). Upon the successful + new ones. (e.g., via MADCAP [RFC2730]). 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 message from a new session member from [SADP-RELATIVE-GROUP] at a particular scope will issue an SADP Response (SADP_RESP) to the [SADP-RELATIVE-GROUP] at the same scope after waiting for a random - amount of time (T) that is calculated as follows: + amount of time (T) that is calculated as follows [HAND98]: Choose a random value X from a uniform random interval [0:1] Let C = 256 Set T = [SADP-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C) Should a member receive a SADP_RESP before its timer it expires it SHALL suppress its own response. This method ensures that close to one session member will respond. 3.3 SADP Server Operation @@ -316,21 +319,23 @@ 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 intermediate scope it MUST NOT announce address information for scopes smaller than one on which the SADP_REQ was received. The effect of allowing larger-scoped information to be announced at lower scopes by SADP servers significantly reduces the number of scopes a new session will have to query. New session members now need only expand the scope until a SADP server is found. This is a marked improvement over the case where no SADP servers exist and the search - must continue until an existing session member is found. + must continue until an existing session member is found. An analysis + of how the pressence of SADP Servers improve SADP protcol performance + can be found in [KT99]. Scope b Boundary Scope a : Scope a and Scope b _________ : ____________ _____________ / \ : / \ / \ |Source at| _____:___\ |SADP Server | /___________ | New Session | |Scope a | SADP_RESP/ | Scopes a,b | \ SADP_REQ | Member | \_________/ : \____________/ ___________\ | Scopes a,b | : SADP_RESP/ \_____________/ : @@ -340,57 +345,72 @@ All SADP messages are sent over UDP, with a destination port of [SADP-PORT]. The common SADP message header (which follows the UDP header), is shown below, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | PTYPE | Num Scopes | Addr Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Largest Scope Group Address | + | Session ID Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Authentication Block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + | Authentication Block | + + + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Version: 8 bits The version defined in this document is version 0. Packet Type (PTYPE): 8 bits The packet types defined in this document are: 0: SADP Request 1: SADP Response 2: SADP New Address Number of Scope Entries (Num Scopes) : 4 bits 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 IANA-assigned address family number to be used for address contained in this message. Currently assigned - values are listed in RFC 1700 [RFC1700]. The values for IP + values are listed in [RFC1700]. The values for IP addresses are: IPv4: 1 IPv6: 2 Session ID Address: 32 bits (IPv4) or 128 bits (IPv6) The group address corresponding to the largest scope for this hierarchy of addresses. Authentication Block: The Authentication Block provides information which can be used to confirm that the sender of the SADP message is a valid member of the session. Session Members that cannot confirm that the - sender of an SADP Request Message MAY ignore it, while new - session members that receive an SADP Response Message MUST - ignore it. (The format of the authentication block is to be - decided) + sender of a SADP Request Message is a session member or a + known SADP Server MAY ignore it, while new session members that + receive a SADP Response Message MUST ignore it. + + The authentication block consists of an MD5 digest that is + constructed by applying the MD5 algorihtm [RFC1321] to these + items in the following order: + + 1) Session Identifer Address + 2) Address of the Session Member making the announcement + 3) The contents of any subsequent SADP Response or SADP New + Address message data. 4.1 SADP Request SADP Request (SADP_REQ) Messages have PTYPE=0, and are sent by new session members that wish to learn which administrative scopes and multicast addresses to use within a particular session. SADP_REQ Messages are sent according to the algorithm described in 3.2. 4.2 SADP Response @@ -424,21 +444,21 @@ Scope X 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. Scope X Session Address : 32 bits (IPv4) or 128 bits (IPv6) Address to be used for the named scope. -4.2 SADP New Address +4.3 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 @@ -498,68 +518,82 @@ yet to be determined) mechanisms that allow spoofed SADP messages to be identified for removal before processing. 7. Acknowledgments The Authors would like to acknowledge Mark Handley for the helpful discussions and feedback which helped shape and refine this document. 8. References - [MADCAP] Patel. B.V., Shah, M., Hanna, S.R., "Multicast Address - 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 Multicast Address Allocation Architecture", Internet - Draft, December 1997. + Draft, draft-ietf-malloc-arch-**.txt, June 2000. - [MZAP] Handley, M., Thaler, D., "Multicast-Scope Zone - Announcement Protocol (MZAP)", - draft-ietf-mboned-mzap-02.txt, Internet-Draft, August, - 1998. + [HAND98] Handley, M., "Session directories and scalable internet + multicast address allocation for private internets", + In Proceedings of ACM SIGCOMM, pp 105-116, 1998. + + [SHARQFEC] Kermode, R., "Scoped Hybrid Automatic Repeat reQuest with + Forward Error Correction (SHARQFEC)", ACM SIGCOMM98, + Vancouver Canada, September 1998. + + [NESTOPT] Kermode, R., "MADCAP Multicast Scope Nesting State + Option", draft-ietf-malloc-madcap-nest-opt-05.txt, + April, 2000. + + [KT99] Kermode, R., & Thaler, D., "Support for reliable Sessions + with a Large Number of Members", First International + Workshop on Networked Group Communication, Pisa Italy, + November 1999 + + [RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest + Algorithm", RFC 1321, April 1992. [RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October 1994. [RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", RFC 1884, December 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP, RFC 2119, March 1997. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP, RFC 2365, July 1998. - [SHARQFEC] Kermode, R., "Scoped Hybrid Automatic Repeat reQuest with - Forward Error Correction (SHARQFEC)", ACM SIGCOMM98, - Vancouver Canada, September 1998. + [RFC2730] Patel. B.V., Shah, M., Hanna, S.R., "Multicast Address + Dynamic Client Allocation Protocol (MADCAP)", + RFC2730, December 1999. + + [RFC2776] Handley, M., Thaler, D., "Multicast-Scope Zone + Announcement Protocol (MZAP)", RFC 2776, February 2000 9. Authors' Addresses Roger Kermode Motorola Australia Research Centre 12 Lord St. - Botany, NSW 2091 + Botany, NSW 2019 Australia - Email: Roger_Kermode@email.mot.com + Email: Roger.Kermode@motorola.com David Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA Email: dthaler@microsoft.com 10. Full Copyright Statement - Copyright (C) The Internet Society (1999). All Rights Reserved. + Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of