idnits 2.17.1 draft-ietf-malloc-masc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 150: '...nt(s). Children MAY be configured wit...' RFC 2119 keyword, line 339: '... loser, it MAY be withdrawn and a ne...' RFC 2119 keyword, line 545: '..., a MASC speaker MUST calculate the va...' RFC 2119 keyword, line 547: '...e OPEN message. The Hold Time MUST be...' RFC 2119 keyword, line 775: '...erval. KEEPALIVE messages MUST NOT be...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 935 has weird spacing: '...is less than ...' == Line 1604 has weird spacing: '... reason to pr...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'INITIATE-CLAIM-DELAY' is mentioned on line 440, but not defined == Missing Reference: 'WAITING-PERIOD' is mentioned on line 745, but not defined == Missing Reference: 'PORT-NUMBER' is mentioned on line 426, but not defined == Missing Reference: 'TLD-ID' is mentioned on line 988, but not defined == Missing Reference: 'HOLDTIME' is mentioned on line 1295, but not defined == Unused Reference: 'API' is defined on line 1943, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AAP' == Outdated reference: A later version (-07) exists of draft-ietf-malloc-api-01 ** Downref: Normative reference to an Informational draft: draft-ietf-malloc-api (ref. 'API') == Outdated reference: A later version (-04) exists of draft-ietf-idmr-gum-02 -- Possible downref: Normative reference to a draft: ref. 'BGMP' ** Obsolete normative reference: RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 1700 (ref. 'IANA') (Obsoleted by RFC 3232) -- No information found for draft-handley-malloc-arch - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MALLOC' ** Obsolete normative reference: RFC 2283 (ref. 'MBGP') (Obsoleted by RFC 2858) == Outdated reference: A later version (-07) exists of draft-ietf-idmr-traceroute-ipm-02 -- Possible downref: Normative reference to a draft: ref. 'MTRACE' == Outdated reference: A later version (-06) exists of draft-ietf-mboned-mzap-00 ** Downref: Normative reference to an Historic draft: draft-ietf-mboned-mzap (ref. 'MZAP') Summary: 15 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MALLOC Working Group Deborah Estrin (USC/ISI) 3 Internet Engineering Task Force Ramesh Govindan (ISI) 4 INTERNET-DRAFT Mark Handley (ISI) 5 August, 1998 Satish Kumar (USC/ISI) 6 Expires February 1999 Pavlin Radoslavov (USC/ISI) 7 Dave Thaler (Microsoft) 9 The Multicast Address-Set Claim (MASC) Protocol 10 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, and 16 its Working Groups. Note that other groups may also distribute working 17 documents as Internet Drafts. 19 Internet Drafts are valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet Drafts as reference material or to cite 22 them other than as a "work in progress". 24 Abstract 26 This document describes the Multicast Address-Set Claim (MASC) protocol 27 which can be used for inter-domain multicast address set allocation. 28 MASC is used by a node (typically a router) to claim and allocate one or 29 more address prefixes to that node's domain. While a domain does not 30 necessarily need to allocate an address set for hosts in that domain to 31 be able to allocate group addresses, allocating an address set to the 32 domain does ensure that inter-domain distribution trees will be 33 locally-rooted, and that traffic will be sent outside the domain only 34 when and where external receivers exist. 36 Copyright Notice 38 Copyright (C) The Internet Society (1998). All Rights Reserved. 40 Draft MASC August 1998 42 1. Introduction 44 This document describes MASC, a protocol for inter-domain multicast 45 address set allocation. The MASC protocol is used by a node (typically 46 a router) to claim and allocate one or more address prefixes to that 47 node's domain. Each prefix has an associated lifetime, and is chosen 48 out of a larger prefix with a lifetime at least as long, in a manner 49 such that prefixes are aggregatable. At any time, each MASC node will 50 typically advertise several prefixes with different lifetimes and 51 scopes, allowing Multicast Address Allocation Servers (MAAS's) in that 52 domain or child MASC domains to choose appropriate addresses for their 53 clients. 55 The set of prefixes (''address set'') associated with a domain is 56 injected into an inter-domain routing protocol (e.g., BGP4+ [MBGP]), 57 where it can be used by an inter-domain multicast tree construction 58 protocol (e.g., BGMP [BGMP]) to construct inter-domain group-shared 59 trees. 61 Note that a domain does not need to allocate an address set for the 62 hosts in that domain to be able to allocate group addresses, nor does 63 allocating necessarily guarantee that hosts in other domains will not 64 use an address in the set (since, for example, hosts are not forced to 65 contact a MAAS before using a group address). Allocating an address set 66 to a domain does, however, ensure that inter-domain multicast 67 distribution trees for any group in the address set will be locally- 68 rooted, and that traffic will be sent outside the given domain only when 69 and where external receivers exist. 71 2. Requirements for Inter-Domain Address Allocation 73 The key design requirements for the inter-domain address allocation 74 mechanism are: 76 o Efficient address space utilization, which naturally implies that 77 address allocations be based on the actual address usage patterns, 78 and therefore that it be dynamic. 80 o Address aggregation, that implies that the address allocation 81 mechanism be hierarchical. 83 o Minimize flux in the allocated address sets (e.g. the address sets 84 should be reused when possible.) 86 Draft MASC August 1998 88 o Robustness, by using decentralized mechanisms. 90 The timeliness in obtaining an address set is not a major design 91 constraint as this is taken care of at a lower level [MALLOC]. 93 3. Overall Architecture 95 The Multicast Address Set Claim (MASC) protocol is used by MASC domains 96 to claim and allocate address sets for use by Multicast Address 97 Allocation Servers (MAASs) within each domain. Typically one or more 98 border routers of each domain that requires multicast address space of 99 its own would run MASC. Throughout this document, the term "MASC 100 domain" refers to a domain that has at least one node running MASC; 101 typically these domains will be Autonomous Systems (AS's). A MASC node 102 (on behalf of its domain) chooses an address set to claim, sends a claim 103 to other MASC domains in the network, and waits while listening for any 104 colliding claims. If there is a collision, the losing claimer gives up 105 the colliding claim and claims a different address set. 107 After a sufficiently long collision-free waiting period, the address set 108 chosen by a MASC node is considered allocated to that node's domain. 109 Three things may then happen: 111 a) The allocated prefix can then be injected as a "multicast route" 112 into the inter-domain routing protocol (e.g., BGP4+ [MBGP]) as 113 "G-RIB" Network Layer Reachability Information (NLRI), where it may 114 be used by an inter-domain multicast routing protocol (e.g., BGMP 115 [BGMP]) to construct group-shared trees. To reduce the size and 116 slow the growth of the G-RIB, MASC nodes may perform CIDR-like 117 aggregation of the multicast NLRI information. This motivates the 118 need for an algorithm to select prefixes for domains in such a way 119 as to ensure good aggregation in addition to achieving good address 120 space utilization. 122 b) The node's domain may assign to itself a sub-prefix which can be 123 used by address allocation servers within the domain. 125 c) Sub-prefixes may be allocated to child domains, if any. 127 3.1. Claim-collide vs. query-response rationale 129 We choose a claim-collide mechanism instead of a query-response 130 mechanism for the following reasons. In a query-response mechanism, 131 Draft MASC August 1998 133 replicas of the MASC node would be needed in parent MASC domains in 134 order to make their responses be robust to failures. This brings about 135 the associated problem of synchronization of the replicas and possibly 136 additional fragmentation of the address space. In addition, even in 137 this mechanism, address collisions would still need to be handled. We 138 believe the proposed claim-collide mechanism is simpler and more robust 139 than a query-response mechanism. 141 4. MASC Topology 143 The domain hierarchy used by MASC is congruent to the somewhat 144 hierarchical structure of the inter-domain topology, e.g., backbones 145 connected to regionals, regionals connected to metropolitan providers, 146 etc. As in BGP, MASC connections are locally configured. A MASC domain 147 that is a customer of other MASC domains will have one or more of those 148 provider domains as its parent. For example, a MASC domain that is a 149 regional provider will choose one (or more) of its backbone provider 150 domains as its parent(s). Children MAY be configured with their parent 151 MASC domain, but in general may use heuristics (e.g. the domain to which 152 they point default unicast routes) to automatically select one or more 153 parent domains. Similarly, parents may be configured with children 154 domains. At the top, a number of Top-Level Domains are connected in a 155 (sparse) mesh and share the global multicast address space. 157 Figure 1 illustrates a sample topology. Double-line links denote 158 intra-domain TCP peering sessions, and single-line links denote inter- 159 domain TCP connections. T1 and T2 are Top-Level Domains (e.g., backbone 160 providers), containing MASC speakers T1a and T2a, respectively. P3 and 161 P4 are regional domains, containing (P3a, P3b), and (P4a, P4b) 162 respectively. P3 has a single customer (or "child"), C5, containing 163 (C5a, C5b, C5c). P4 has three children, C5, C6, C7, containing (C5a, 164 C5b, C5c), (C6a, C6b), and (C7a) respectively. 166 Draft MASC August 1998 168 T1a-----------T2a 169 | | 170 | | 171 | | 172 P3a====P3b P4a====P4b 173 | | / | / | \ 174 | | _______/ | / | \ 175 | | / | / | \______ 176 | | / | / | \ 177 C5a====C5b C6a====C6b C7a 178 \\ // 179 \\// 180 C5c 182 Figure 1: Example MASC Topology 184 All MASC communications use TCP. Each MASC node is connected to and 185 communicates directly with other MASC nodes. The local node acts in 186 exactly one of the following four roles with respect to each remote 187 note: 189 INTERNAL_PEER 190 The local and remote nodes are both in the same MASC domain. For 191 example, P4b is an INTERNAL_PEER of P4a. 193 CHILD 194 A customer relationship exists whereby the local node may obtain 195 address space from the remote node. For example, C6a is a CHILD in 196 its session with P4a. 198 PARENT 199 A provider relationship exists whereby the remote node may obtain 200 address space from the local node. For example, T2a is a PARENT in 201 its session with P4a. Whether space is actually requested is up to 202 the implementation and local policy configuration. 204 SIBLING 205 No customer-provider relationship exists. For example, T2a is a 206 SIBLING in its session with T1a. 208 A node's message will be propagated to its parent, all siblings with the 209 same parent, and its children. Since a domain need not have a direct 210 peering session with every sibling, a MASC domain must propagate 211 Draft MASC August 1998 213 messages from a child domain to other children, can propagate messages 214 from a parent domain to other siblings, and, if a Top-Level Domain, it 215 must propagate messages from a sibling to other siblings, otherwise may 216 propagate messages from a sibling domain to its parent and other 217 siblings. 219 5. Address Space Structure 221 5.1. Managed vs Locally-Allocated Space 223 Each domain has a "Managed" Address Set, and a "Locally-Allocated" 224 Address Set. The "managed" space includes all address space which a 225 domain has successfully claimed via MASC. The "locally-allocated" 226 space, on the other hand, includes all address space which address 227 allocation servers inside the domain may use. Thus, the locally- 228 allocated space is a subset of the managed space, and refers to the 229 portion which a domain allocates for its own use. 231 For leaf domains (ones with no children), these two sets are identical, 232 since all claimed space is allocated for local use. A parent domain, on 233 the other hand, "manages" all address space which it has claimed via 234 MASC, while sub-prefixes can be allocated to itself and to its children. 236 5.2. Prefix lifetimes 238 Each prefix has an associated lifetime. If a domain wants to use a 239 prefix longer than its lifetime, that domain must "renew" the prefix 240 BEFORE its lifetime expires (see Section 6.2). If the lifetime cannot 241 be extended, then the domain should either retry later to extend, or 242 should choose and claim another prefix. 244 After a prefix's lifetime expires, MASC nodes in the domain that own 245 that prefix must stop using that prefix. The corresponding entry from 246 the G-RIB database must be removed, and all information associated with 247 the expired prefix may be deleted from the MASC node's local memory. 249 5.3. Active vs. deprecated prefixes 251 Each prefix advertised by a parent to its children can be either 252 "active" or "deprecated". A "deprecated" prefix is a prefix that the 253 parent wishes to discontinue to use after its lifetime expires. The 254 "active" prefixes only are candidates for size expansion or lifetime 255 Draft MASC August 1998 257 extension. Usually, this information will be used by a child as a hint 258 to know which of the parent's prefixes might have their lifetime 259 extended. 261 5.4. Administratively-Scoped Address Allocation 263 MASC can also be used for sub-allocating prefixes of addresses within an 264 administrative scope zone [SCOPE]. A MASC node can learn what scopes it 265 resides within by listening to MZAP [MZAP] messages. 267 A "Zone TLD" is a domain which has no parent domain within the scope 268 zone. Zone TLDs act as TLDs for the prefix associated with the scope. 269 Figure 2 gives an example, where a scope boundary around domains P3 and 270 C5 has been added to Figure 1. Domain P3 is a Zone TLD, since its only 271 parent (T1) is outside the boundary. Hence, P3 can claim space directly 272 out of the prefix associated with the scope itself. Domain C5, on the 273 other hand, has a parent within the scope (namely, P3), and hence is not 274 a Zone TLD. 276 Draft MASC August 1998 278 T1a-----------T2a 279 | | 280 ............|....... | 281 . | . | 282 . P3a====P3b . P4a 283 . | | . / 284 . | | _______/ 285 . | | / . 286 . | | / . 287 . C5a====C5b . 288 . \\ // . 289 . \\// . 290 . C5c . 291 . . 292 . Admin Scope Zone . 293 .................... 295 Figure 2: Scope Zone Example 297 It is assumed that the role of a node (as discussed in Section 4) with 298 respect to a given peering session is the same for every scope in which 299 both ends are contained. A peering session that crosses a scope 300 boundary (such as the session between C5b and P4a in Figure 2) is 301 ignored when propagating messages that pertain to the given scope. That 302 is, such messages are not sent across such sessions. 304 6. Protocol Details 306 6.1. Claiming Space 308 When a MASC node, on behalf of a MASC domain, needs more address space, 309 it decides locally the size and the value of the address prefix(es) it 310 will claim from one of its parents. For example, the decision might be 311 based on the knowledge this node has about its parent's address set, its 312 siblings' claims and allocations, its own address set, the claim 313 messages from its siblings, and/or the demand pattern of its children 314 and the local domain. A sample algorithm is given in Appendix A. 316 A MASC node which is not in a top-level domain can initiate a claim 317 toward a parent MASC domain if and only if it currently has an 318 established connection with at least one node in that parent domain. 320 After the prefix address and size are decided, the claim proceeds as 321 Draft MASC August 1998 323 follows: 325 a) The claim is scheduled to be sent after a random delay in the 326 interval (0, [INITIATE-CLAIM-DELAY]). If a claim originated by a 327 node from the same MASC domain is received, and that claim eliminates 328 the need for the local claim, the local claim is canceled and no 329 further action is taken. 331 b) The claim is sent to one of the parents (if the domain is not a top- 332 level domain), all known siblings with the same parent, and all 333 internal peers. A Claim-Timer is then started at [WAITING-PERIOD], 334 and the MASC node starts listening for colliding claims. 336 c) If a colliding claim is received while the Claim-Timer is running, 337 that claim is compared with the locally initiated claim using the 338 function described in Section 6.1.1. If the local claim is the 339 loser, it MAY be withdrawn and a new prefix must be chosen to claim. 340 If the winning claim was originated by a node from the same MASC 341 domain, no new claim will be initiated. If the local claim is the 342 winner, no actions need to be taken. 344 d) If the Claim-Timer expires, the claimed prefix becomes associated 345 with the claimer's domain, i.e. it is considered allocated to that 346 domain and the following actions must be performed: 348 o Advertise the prefix to its parent, and to all siblings with the 349 same parent, by sending a PREFIX_IN_USE claim to them. 351 o Inject the prefix into the G-RIB of the inter-domain routing 352 protocol. 354 o Send a PREFIX_MANAGED message to all children and internal peers, 355 informing them that they may issue claims within the managed space. 356 A sub-prefix may then be claimed for local usage. 358 Each MASC node receives all claims from its siblings and children. A 359 received claim must be evaluated against all claims saved in the local 360 cache using the function described in Section 6.1.1. The output of the 361 function will define the further processing of that claim (see Section 362 12). 364 Draft MASC August 1998 366 6.1.1. Claim Comparison Function 368 Each claim message includes: 370 o a "type", being one of: PREFIX_IN_USE, CLAIM_DENIED, CLAIM_TO_EXPAND, 371 or NEW_CLAIM (PREFIX_MANAGED and WITHDRAW are not considered as 372 claims that have to be compared) 374 o timestamp when the claim was initiated 376 o the claimed prefix and lifetime 378 o MASC Identifier of the node that originated the claim 380 When two claims are compared, first the type is compared in the 381 following order: 383 PREFIX_IN_USE > CLAIM_DENIED > CLAIM_TO_EXPAND > NEW_CLAIM 385 If the type is the same, then the timestamps are used to compare the 386 claims. In practice, two claims will have the same type if the type is 387 either NEW_CLAIM (ordinary collision) or PREFIX_IN_USE (signal for 388 clash). When the timestamps are compared, the claim with the smallest, 389 i.e. earliest timestamp wins. If the timestamps are the same, then the 390 claim with the smallest Origin Node Identifier wins. 392 6.2. Renewing an Existing Claim 394 The procedure for extending the lifetime of prefixes already in use is 395 the same as claiming new space (see Section 6.1), except that the claim 396 type must be CLAIM_TO_EXPAND, while the Address and the Mask of the 397 claim (see Section 8.3) must be the same as the already allocated 398 prefix. If the Claim-Timer expires and there is no collision, the 399 desired lifetime is assumed. 401 6.3. Expanding an Existing Prefix 403 The procedure for extending the lifetime of prefixes already in use is 404 the same as claiming new space (see Section 6.1), except that the claim 405 type must be CLAIM_TO_EXPAND, while the Address and the Mask of the 406 claim (see Section 8.3) must be set to the desired values. If the 407 Claim-Timer expires and there is no collision, the desired larger prefix 408 is associated with the local domain. 410 Draft MASC August 1998 412 6.4. Releasing Allocated Space 414 If the lifetime of a prefix allocated to the local domain expires and 415 the domain does not need to reuse it, all associated with this prefix 416 resources are deleted and no further actions are taken. If the lifetime 417 of the prefix has not expired, and if no subranges of that prefix have 418 being allocated for local usage or by some of the children domains, the 419 space may be released by sending a withdraw message to the parent domain 420 and all known siblings of the same domain. 422 7. Constants 424 MASC uses the following constants: 426 [PORT-NUMBER] 427 TODO. The TCP port number used to listen for incoming MASC 428 connections. 430 [WAITING-PERIOD] 431 The amount of time that must pass between a new claim, and a 432 PREFIX_IN_USE. This must be long enough to reasonably span any 433 single inter-domain network partition. Default: 172800 seconds 434 (i.e. 48 hours). 436 [INITIATE-CLAIM-DELAY] 437 The amount of time a MASC node must wait before initiating a new 438 claim or claim for space expansion must be a random value in the 439 interval (0, [INITIATE-CLAIM-DELAY]). Default value for 440 [INITIATE-CLAIM-DELAY]: 600 seconds (i.e. 10 minutes). 442 [TLD-ID] 443 The Paret Domain Identifier used by a Top-Level Domain (which has 444 no parent). Must be 0. 446 [HOLDTIME] 447 The amount of time that must pass without any messages received 448 from a remote node before considering the connection is down. 449 Default: 240 seconds (i.e. 4 minutes). 451 8. Message Formats 453 This section describes message formats used by MASC. 455 Draft MASC August 1998 457 Messages are sent over a reliable transport protocol connection. A 458 message is processed only after it is entirely received. The maximum 459 message size is 4096 octets. All implementations are required to 460 support this maximum message size. 462 All fields labeled "Reserved" below must be transmitted as 0, and 463 ignored upon receipt. 465 8.1. Message Header Format 467 Each message has a fixed-size (4-byte) header. There may or may not be 468 a data portion following the header, depending on the message type. The 469 layout of these fields is shown below: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Length | Type | Reserved | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Length: 478 This 2-octet unsigned integer indicates the total length of the 479 message, including the header, in octets. Thus, e.g., it allows 480 one to locate in the transport-level stream the start of the next 481 message. The value of the Length field must always be at least 4 482 and no greater than 4096, and may be further constrained, depending 483 on the message type. No "padding" of extra data after the message 484 is allowed, so the Length field must have the smallest value 485 required given the rest of the message. 487 Type: 488 This 1-octet unsigned integer indicates the type code of the 489 message. The following type codes are defined: 491 1 - OPEN 492 2 - UPDATE 493 3 - NOTIFICATION 494 4 - KEEPALIVE 496 Draft MASC August 1998 498 8.2. OPEN Message Format 500 After a transport protocol connection is established, the first message 501 sent by each side is an OPEN message. If the OPEN message is 502 acceptable, a KEEPALIVE message confirming the OPEN is sent back. Once 503 the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may 504 be exchanged. 506 The minimum length of the OPEN message is 16 octets (including message 507 header). In addition to the fixed-size MASC header, the OPEN message 508 contains the following fields: 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Version | Reserved |Rol| Hold Time | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | My Domain Identifier | Parent's Domain Identifier | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | MASC Node Identifier | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | | 520 + (Optional Parameters) | 521 | | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Version: 525 This 1-octet unsigned integer indicates the protocol version number 526 of the message. The current MASC version number is 1. 528 Reserved: 529 Must be zero. Ignored by the receiver. 531 My Role (Rol): 532 The proposed relationship of the sending system to the receiving 533 system: 534 0 = INTERNAL_PEER (sent from one internal peer to another) 535 1 = CHILD (sent from a child to its parent) 536 2 = SIBLING (sent from one sibling to another) 537 3 = PARENT (sent from a parent to its child) 539 Hold Time: 540 This 2-octet unsigned integer indicates the number of seconds that 541 the sender proposes for the value of the Hold Timer. Upon receipt 543 Draft MASC August 1998 545 of an OPEN message, a MASC speaker MUST calculate the value of the 546 Hold Timer by using the smaller of its configured Hold Time and the 547 Hold Time received in the OPEN message. The Hold Time MUST be 548 either zero or at least three seconds. An implementation may 549 reject connections on the basis of the Hold Time. The calculated 550 value indicates the maximum number of seconds that may elapse 551 between the receipt of successive KEEPALIVE and/or UPDATE messages 552 by the sender. 554 My Domain Identifier: 555 This 2-octet unsigned integer indicates the Autonomous System 556 number of the sender. 558 Parent's Domain Identifier: 559 This 2-octet unsigned integer indicates the Autonomous System 560 number of the sender's parent. It is set to [TLD-ID] if the sender 561 is a TLD. This field is used to determine the parent of a sibling, 562 for use when propagating claims. 564 MASC Node Identifier: 565 This 4-octet unsigned integer indicates the MASC Node Identifier of 566 the sender. A given MASC speaker sets the value of its MASC Node 567 Identifier to a globally-unique value assigned to that MASC speaker 568 (e.g., an IPv4 address). The value of the MASC Node Identifier is 569 determined on startup and is the same for every MASC session 570 opened. 572 Optional Parameters: 573 This field may contain a list of optional parameters, where each 574 parameter is encoded as a triplet. The combined length of all optional 576 parameters can be derived from the Length field in the message 577 header. 579 0 1 580 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 582 | Parm. Type | Parm. Length | Parameter Value (variable) 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 585 Parameter Type is a one octet field that unambiguously identifies 586 individual parameters. Parameter Length is a one octet field that 587 contains the length of the Parameter Value field in octets. 588 Parameter Value is a variable length field that is interpreted 589 according to the value of the Parameter Type field. 591 Draft MASC August 1998 593 This document defines the following Optional Parameters: 595 a) Authentication Information (Parameter Type 1): 596 This optional parameter may be used to authenticate a MASC 597 speaker. The Parameter Value field contains a 1-octet 598 Authentication Code followed by a variable length Authentication 599 Data. 601 0 1 2 3 4 5 6 7 8 602 +-+-+-+-+-+-+-+-+ 603 | Auth. Code | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | | 606 | Authentication Data | 607 | | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Authentication Code: 612 This 1-octet unsigned integer indicates the authentication 613 mechanism being used. Whenever an authentication mechanism is 614 specified for use within MASC, three things must be included in 615 the specification: 617 o the value of the Authentication Code which indicates use of 618 the mechanism, 620 o the form and meaning of the Authentication Data, and 622 o the algorithm for computing values of Marker fields. 624 Note that a separate authentication mechanism may be used in 625 establishing the transport level connection. 627 Authentication Data: 629 The form and meaning of this field is a variable-length field 630 depend on the Authentication Code. 632 b) Parents Information (Parameter Type 2): 633 This optional parameter may be used to carry the Parents' Domain 634 IDs. The Parameter Value field contains a number of 2-octet fields 636 Draft MASC August 1998 638 filled with the Domain ID of each MASC parent domain. 640 8.3. UPDATE Message Format 642 UPDATE messages are used to transfer Claim/Collision/PrefixManaged 643 information between MASC speakers. The UPDATE message always includes 644 the fixed-size MASC header, and one or more attributes as described 645 below. The minimum length of the UPDATE message is 32 octets (including 646 the message header). 648 Each attribute is of the form: 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Length | Type | Reserved | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Data ... | 656 . . 657 . . 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 All attributes are 4-byte aligned. 661 Length: 662 The Length is the length of the entire attribute, including the 663 length, type, and data fields. If other attributes are nested 664 within the data field, the length includes the size of all such 665 nested attributes. 667 Type: 669 Types 128-255 are reserved for "optional" attributes. If a 670 required attribute is unrecognized, a NOTIFICATION with UPDATE 671 Error Code and Unrecognized Required Attribute subcode will be 672 sent. 674 Unrecognized optional attributes are simply ignored. 676 0 = PREFIX_IN_USE (prefix is being used by the origin) 677 1 = CLAIM_DENIED (origin refuses your claim and will not propagate it) 678 2 = CLAIM_TO_EXPAND (origin is trying to expand the size of an 680 Draft MASC August 1998 682 existing prefix) 683 3 = NEW_CLAIM (origin is trying to claim a new prefix) 684 4 = PREFIX_MANAGED (parent is informing child of space available) 685 5 = WITHDRAW (origin is withdrawing a previous claim) 687 Types 0-3 are collectively called "CLAIMs". The message format below 688 describes the encoding of a CLAIM, PREFIX_MANAGED and WITHDRAW. 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 |A|Rol| Reserved | AddrFam | Origin Domain Identifier | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Origin Node Identifier | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Claim Timestamp | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Claim Lifetime | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Claim Holdtime | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Address (variable length) | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Mask (variable length) | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Reserved/Res.: 708 Must be zero. Ignored by the receiver. 710 A-bit: 711 ACTIVE_PREFIX bit. If set, indicates that the advertised address 712 prefix is Active, otherwise the prefix is Deprecated, i.e. non- 713 active (see Section 5.2). 715 Rol: 716 The relationship/role of the Origin of the message to the node 717 sending that message. 718 0 = INTERNAL (originated by the sender's domain) 719 1 = CHILD (originated by a child of the sender's domain) 720 2 = SIBLING (originated by a sibling of the sender's domain) 721 3 = PARENT (originated by a parent of the sender's domain) 723 Origin Domain Identifier: 724 The AS number of the claim originator. 726 Draft MASC August 1998 728 Origin Node Identifier: 729 The MASC Node ID of the claim originator. 731 Claim Timestamp: 732 The timestamp of the claim when it was originated. The timestamp 733 is expressed in number of seconds since midnight (0 hour), January 734 1, 1970, Greenwich. 736 Claim Lifetime: 737 The time in seconds between the Claim Timestamp, and the time at 738 which the prefix will become free. 740 Claim Holdtime: 741 The time in seconds between the Claim Timestamp, and the time at 742 which the claim should be deleted from the local cache. For 743 PREFIX_IN_USE and PREFIX_MANAGED claims it should be equal to 744 Claim Lifetime; for CLAIM_TO_EXPAND, NEW_CLAIM, and CLAIM_DENIED 745 it should be equal to [WAITING-PERIOD]. 747 AddrFam: 748 The IANA-assigned address family number of the encoded prefix 749 [IANA]. These include (among others): 751 Number Description 752 ------ ----------- 753 1 IP (IP version 4) 754 2 IPv6 (IP version 6) 756 Address: 757 The address associated with the given prefix to be encoded. The 758 length is determined based on the Address Family (e.g. 4 for IPv4, 759 16 for IPv6) 761 Mask: 762 The mask associated with the given prefix. The length is the same 763 as the Address field and is determined based on the Address 764 Family. The field contains the full bitmask. 766 8.4. KEEPALIVE Message Format 768 MASC does not use any transport protocol-based keep-alive mechanism to 769 determine if peers are reachable. Instead, KEEPALIVE messages are 770 exchanged between peers often enough as not to cause the Hold Timer to 771 Draft MASC August 1998 773 expire. A reasonable maximum time between the last KEEPALIVE or UPDATE 774 message sent, and the time at which a KEEPALIVE message is sent, would 775 be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be 776 sent more frequently than one per second. An implementation MAY adjust 777 the rate at which it sends KEEPALIVE messages as a function of the Hold 778 Time interval. 780 If the negotiated Hold Time interval is zero, then periodic KEEPALIVE 781 messages MUST NOT be sent. 783 A KEEPALIVE message consists of only a message header, and has a length 784 of 4 octets. 786 8.5. NOTIFICATION Message Format 788 A NOTIFICATION message is sent when an error condition is detected. 789 Depending on the error condition, the MASC connection might or must be 790 closed immediately after sending the message. If the connection is to 791 be closed, the C-bit must be set. 793 In addition to the fixed-size MASC header, the NOTIFICATION message 794 contains the following fields: 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 |C| Error code | Error subcode | Data | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 800 | | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 C-bit: 804 Close-bit. If set, the connection will be closed. 806 Error Code: 807 This 7-bit unsigned integer indicates the type of NOTIFICATION. 808 The following Error Codes have been defined: 809 Error Code Symbolic Name Reference 811 1 Message Header Error Section 9.1 813 2 OPEN Message Error Section 9.2 815 3 CLAIM Message Error Section 9.3 817 Draft MASC August 1998 819 4 Hold Timer Expired Section 9.4 821 5 Finite State Machine Error Section 9.5 823 6 NOTIFICATION Message Error Section 9.6 825 7 Cease Section 9.7 827 Error subcode: 828 This 1-octet unsigned integer provides more specific information 829 about the nature of the reported error. Each Error Code may have 830 one or more Error Subcodes associated with it. If no appropriate 831 Error Subcode is defined, then a zero (Unspecific) value is used 832 for the Error Subcode field, and the C-bit must be set (i.e. the 833 connection will be closed). The used notation in the error 834 description below is: MC = Must Close connection = C-bit set; CC = 835 Can Close connection = C-bit is not set. 837 Message Header Error subcodes: 838 0 - Unspecific (MC) 839 1 - Bad Message Length (MC) 840 2 - Bad Message Type (MC) 842 OPEN Message Error subcodes: 844 0 - Unspecific (MC) 845 1 - Unsupported Version Number (MC) 846 2 - Bad Peer AS (MC) 847 4 - Unsupported Optional Parameter (CC) 848 5 - Authentication Failure (MC) 849 6 - Unacceptable Hold Time (MC) 850 7 - Invalid Parent Configuration (MC) 851 8 - Inconsistent Role (MC) 852 9 - Bad Parent Domain ID (MC) 853 10 - No Common Parent (MC) 855 UPDATE Message Error subcodes: 857 0 - Unspecific (MC) 858 1 - Malformed Attribute List (MC) 859 2 - Unrecognized Required Attribute (CC) 860 5 - Attribute Length Error (MC) 861 10 - Invalid Address field (CC) 862 11 - Invalid Mask field (CC) 863 12 - Non-Contiguous Mask (CC) 865 Draft MASC August 1998 867 13 - Unrecognized Address Family (MC) 868 14 - Claim Type Error (CC) 869 15 - Origin Domain ID Error (CC) 870 16 - Origin Node ID Error (CC) 871 17 - Claim Lifetime Too Short (CC) 872 18 - Claim Lifetime Too Long (CC) 873 19 - Claim Timestamp Too Old (CC) 874 20 - Claim Timestamp Too New (CC) 875 21 - Claim Prefix Size Too Small (CC) 876 22 - Claim Prefix Size Too Large (CC) 877 23 - Illegal Origin Role Error (CC) 879 Hold Timer Expired subcodes (the C-bit is always set): 881 0 - Unspecific (MC) 883 Finite State Machine Error subcodes: 885 0 - Unspecific (MC) 886 1 - Open/Close MASC Connection FSM Error (MC) 888 Cease subcodes (the C-bit is always set): 890 0 - Unspecific (MC) 892 NOTIFICATION subcodes (the C-bit is always set): 894 0 - Unspecific (MC) 895 Data: 896 This variable-length field is used to diagnose the reason for the 897 NOTIFICATION. The contents of the Data field depend upon the Error 898 Code and Error Subcode. See Section 9 for more details. 900 Note that the length of the Data field can be determined from the 901 message Length field by the formula: 903 Message Length = 6 + Data Length 905 The minimum length of the NOTIFICATION message is 6 octets (including 906 message header). 908 Draft MASC August 1998 910 9. MASC Error Handling 912 This section describes actions to be taken when errors are detected 913 while processing MASC messages. MASC Error Handling is similar to that 914 of BGP [BGP]. 916 When any of the conditions described here are detected, a NOTIFICATION 917 message with the indicated Error Code, Error Subcode, and Data fields is 918 sent. In addition, the MASC connection might be closed. If no Error 919 Subcode is specified, then a zero (Unspecific) must be used. 921 The phrase "the MASC connection is closed" means that the transport 922 protocol connection has been closed and that all resources for that MASC 923 connection have been deallocated. 925 Unless specified explicitly, the Data field of the NOTIFICATION message 926 that is sent to indicate an error is empty. 928 9.1. Message Header error handling 930 All errors detected while processing the Message Header are indicated by 931 sending the NOTIFICATION message with Error Code Message Header Error. 932 The Error Subcode elaborates on the specific nature of the error. 934 If the Length field of the message header is less than 4 or greater than 935 4096, or if the Length field of an OPEN message is less than the 936 minimum length of the OPEN message, or if the Length field of an UPDATE 937 message is less than the minimum length of the UPDATE message, or if the 938 Length field of a KEEPALIVE message is not equal to 4, then the Error 939 Subcode is set to Bad Message Length. The Data field contains the 940 erroneous Length field. 942 If the Type field of the message header is not recognized, then the 943 Error Subcode is set to Bad Message Type. The Data field contains the 944 erroneous Type field. 946 9.2. OPEN message error handling 948 All errors detected while processing the OPEN message are indicated by 949 sending the NOTIFICATION message with Error Code OPEN Message Error. 950 The Error Subcode elaborates on the specific nature of the error. 952 If the version number contained in the Version field of the received 953 Draft MASC August 1998 955 OPEN message is not supported, then the Error Subcode is set to 956 Unsupported Version Number. The Data field is a 1-octet unsigned 957 integer, which indicates the largest locally supported version number 958 less than the version the remote MASC node bid (as indicated in the 959 received OPEN message). 961 If the Autonomous System field of the OPEN message is unacceptable, then 962 the Error Subcode is set to Bad Peer AS. The determination of 963 acceptable Autonomous System numbers is outside the scope of this 964 protocol. 966 If the Hold Time field of the OPEN message is unacceptable, then the 967 Error Subcode MUST be set to Unacceptable Hold Time. An implementation 968 MUST reject Hold Time values of one or two seconds. An implementation 969 MAY reject any proposed Hold Time. An implementation which accepts a 970 Hold Time MUST use the negotiated value for the Hold Time. 972 If one of the Optional Parameters in the OPEN message is not recognized, 973 then the Error Subcode is set to Unsupported Optional Parameters. 975 If the OPEN message carries Authentication Information (as an Optional 976 Parameter), then the corresponding authentication procedure is invoked. 977 If the authentication procedure (based on Authentication Code and 978 Authentication Data) fails, then the Error Subcode is set to 979 Authentication Failure. 981 If the remote system's proposed Role conflicts with its expected role 982 (based on the local system's configured Role), then the Error Subcode is 983 set to Inconsistent Role. The Data field is 1-octet long, and contains 984 the local system's configured Role. 986 If the remote system's proposed Role is INTERNAL_PEER, and either (but 987 not both) the local system or the remote system's Parent's Domain ID is 988 [TLD-ID], then the Error Subcode is set to Invalid Parent Configuration. 989 The Data field must be filled with all the local system's Parent Domain 990 IDs. 992 If one of the remote system's Parent Domain IDs is unacceptable, then 993 the Error Subcode is set to Bad Parent Domain ID and the Data field must 994 be filled with all unacceptable Parent Domain IDs. The determination of 995 acceptable Parent Domain ID is outside the scope of this protocol. 997 If the remote system is supposed to be a sibling, but it does not have a 998 common parent (based on the Parents Domain ID information in the OPEN 999 message), the Error Subcode is set to No Common Parent, and the Data 1000 Draft MASC August 1998 1002 field is filled with all Parent's Domain IDs of the local MASC domain. 1004 9.3. UPDATE message error handling 1006 All errors detected while processing the UPDATE message are indicated by 1007 sending the NOTIFICATION message with Error Code UPDATE Message Error. 1008 The error subcode elaborates on the specific nature of the error. 1010 If any recognized attribute has an Attribute Length that conflicts with 1011 the expected length (based on the attribute type code), then the Error 1012 Subcode is set to Attribute Length Error. The Data field contains the 1013 erroneous attribute (type, length and value). 1015 If the Address field includes an invalid address (except 0), then the 1016 Error Subcode is set to Invalid Address. In addition, the Data field 1017 must contain the whole UPDATE message (excluding the Message Header). 1019 If the Mask field includes an invalid mask (for example, starting with 1020 0), then the Error Subcode is set to Invalid Mask. In addition, the Data 1021 field must contain the whole UPDATE message (excluding the Message 1022 Header). 1024 If the Mask field includes a non-contiguous bitmask, and that MASC 1025 server does not support, or is not configured to use non-contiguous 1026 masks, then the Error Subcode is set to Non-Contiguous Mask. In 1027 addition, the Data field must contain the whole UPDATE message 1028 (excluding the Message Header). 1030 If the Address Family is unrecognized, then the Error Subcode is set to 1031 Unrecognized Address Family. In addition, the Data field must contain 1032 the first 28 octets of the UPDATE message (excluding the Message 1033 Header). 1035 If the Origin Role/Claim Type combination is not one of the following, 1036 then the Error Subcode is set to Claim Type Error ("x" = "any", i.e. 1037 0/1) 1039 Origin Claim 1040 A Role Type 1042 x ICSP PREFIX_IN_USE (0) 1043 0 ICSP CLAIM_DENIED (1) 1044 0 ICSP CLAIM_TO_EXPAND (2) 1045 0 ICSP NEW_CLAIM (3) 1047 Draft MASC August 1998 1049 x I SP PREFIX_MANAGED (4) 1051 In addition, the Data Field must contain the whole UPDATE message 1052 (excluding the Message Header). 1054 If there is a reason to believe that the Origin Domain ID is invalid 1055 (for example, if it is 0), then the Error Subcode is set to Origin 1056 Domain ID Error. In addition, the Data field must contain the whole 1057 UPDATE message (excluding the Message Header). The same applies for 1058 Origin Node ID (the corresponding error is Origin Node ID Error). 1060 If a node (usually a parent receiving a claim from a child) thinks that 1061 the Claim Lifetime is too short (for example, less than 172800, i.e. 48 1062 hours), it SHOULD send an UPDATE Message Error with subcode Claim 1063 Lifetime Too Short. In addition, the Data field must contain the whole 1064 UPDATE message (excluding the Message Header). 1066 If a node (usually a parent receiving a claim from a child) thinks the 1067 Claim Lifetime is too long (for example, more than 15,768,000, i.e. half 1068 year), then it SHOULD send a UPDATE Message Error with subcode Claim 1069 Lifetime Too Long. In addition, the Data field must contain the whole 1070 UPDATE message (excluding the Message Header). Note that usually a 1071 parent MASC node should send first CLAIM_DENIED collision messages with 1072 Claim Lifetime field filled with the longest acceptable lifetime. If 1073 the child refuses to claim with shorter lifetime, then Claim Lifetime 1074 Too Long should be sent. 1076 If a node (usually a parent receiving a claim from a child) thinks the 1077 Claim Timestamp is too small, i.e. too old (for example, if a node is 1078 self-confident that its clock is quite accurate), then it SHOULD send a 1079 UPDATE Message Error with subcode Claim Timestamp Too Old. In addition, 1080 the Data field must contain the whole UPDATE message (excluding the 1081 Message Header). 1083 If a node (usually a parent receiving a claim from a child) thinks the 1084 Claim Timestamp is too large, i.e. too new (for example, if a node is 1085 self-confident that its clock is quite accurate), then it SHOULD send a 1086 UPDATE Message Error with subcode Claim Timestamp Too New. In addition, 1087 the Data field must contain the whole UPDATE message (excluding the 1088 Message Header). 1090 If a node (usually a parent receiving a claim from a child) thinks that 1091 the prefix size implied by the Mask field is too small (for example, 1092 smaller than 16 addresses), then it SHOULD send a UPDATE Message Error 1093 with subcode Claim Prefix Size Too Small. In addition, the Data field 1094 Draft MASC August 1998 1096 must contain the whole UPDATE message (excluding the Message Header). 1098 If a node (usually a parent receiving a claim from a child) thinks that 1099 the prefix size implied by the Mask field is too large, then it COULD 1100 send a UPDATE Message Error with subcode Claim Prefix Size Too Large. 1101 In addition, the Data field must contain the whole UPDATE message 1102 (excluding the Message Header). Note that usually a parent MASC node 1103 should send first CLAIM_DENIED collision messages for some subrange of 1104 the child's large claimed address range. If the child refuses to shrink 1105 the claim size, then Claim Prefix Size Too Large should be sent. 1107 If the received UPDATE message's computed Updated Origin Role is illegal 1108 (see Table 1), then the Error Subcode is set to Illegal Origin Role 1109 Error. In addition, the Data field must contain the whole UPDATE 1110 message (excluding the Message Header). 1112 If any other error is encountered when processing attributes, then the 1113 Error Subcode is set to Malformed Attribute List, and the problematic 1114 attribute is included in the data field. 1116 9.4. Hold Timer Expired error handling 1118 If a system does not receive successive KEEPALIVE and/or UPDATE and/or 1119 NOTIFICATION messages within the period specified in the Hold Time field 1120 of the OPEN message, then the NOTIFICATION message with Hold Timer 1121 Expired Error Code must be sent and the MASC connection closed. 1123 9.5. Finite State Machine error handling 1125 Any error detected by the MASC Finite State Machine (e.g., receipt of an 1126 unexpected event) is indicated by sending the NOTIFICATION message with 1127 Error Code Finite State Machine Error. The Error Subcode elaborates on 1128 the specific nature of the error. 1130 9.6. NOTIFICATION message error handling 1132 If a node sends a NOTIFICATION message, and there is an error in that 1133 message, and the C-bit of that message is not set, a NOTIFICATION with 1134 C-bit set, Error Code of NOTIFICATION Error, and subcode Unspecific must 1135 be sent. In addition, the Data field must include the erratic 1136 NOTIFICATION message. However, if the erratic NOTIFICATION message had 1137 Draft MASC August 1998 1139 the C-bit set, then any error, such as an unrecognized Error Code or 1140 Error Subcode, should be noticed, logged locally, and brought to the 1141 attention of the administration of the remote node. The means to do 1142 this, however, lies outside the scope of this document. 1144 9.7. Cease 1146 In absence of any fatal errors (that are indicated in this section), a 1147 MASC node may choose at any given time to close its MASC connection by 1148 sending the NOTIFICATION message with Error Code Cease. However, the 1149 Cease NOTIFICATION message must not be used when a fatal error indicated 1150 by this section does exist. 1152 9.8. Connection Collision Detection 1154 If a pair of MASC speakers try simultaneously to establish a TCP 1155 connection to each other, then two parallel connections between this 1156 pair of speakers might well be formed. We refer to this situation as 1157 connection collision. Clearly, one of these connections must be closed. 1159 Based on the value of the MASC Node Identifier a convention is 1160 established for detecting which MASC connection is to be preserved when 1161 a connection collision does occur. The convention is to compare the 1162 MASC Node Identifiers of the remote nodes involved in the collision and 1163 to retain only the connection initiated by the MASC speaker with the 1164 higher-valued MASC Node Identifier. 1166 Upon receipt of an OPEN message, the local system must examine all of 1167 its connections that are in the OpenConfirm state. A MASC speaker may 1168 also examine connections in an OpenSent state if it knows the MASC Node 1169 Identifier of the remote node by means outside of the protocol. If 1170 among these connections there is a connection to a remote MASC speaker 1171 whose MASC Node Identifier equals the one in the OPEN message, then the 1172 local system performs the following connection collision resolution 1173 procedure: 1175 1. The MASC Node Identifier of the local system is compared to the MASC 1176 Node Identifier of the remote system (as specified in the OPEN 1177 message). 1179 2. If the value of the local MASC Node Identifier is less than the 1180 remote one, the local system closes MASC connection that already 1181 exists (the one that is already in the OpenConfirm state), and 1183 Draft MASC August 1998 1185 accepts MASC connection initiated by the remote system. 1187 3. Otherwise, the local system closes the newly created MASC connection 1188 (the one associated with the newly received OPEN message), and 1189 continues to use the existing one (the one that is already in the 1190 OpenConfirm state). 1192 Comparing MASC Node Identifiers is done by treating them as (4-octet 1193 long) unsigned integers. 1195 A connection collision with an existing MASC connection that is in the 1196 Established state causes unconditional closing of the newly created 1197 connection. Note that a connection collision cannot be detected with 1198 connections that are in Idle, or Connect, or Active states (see Section 1199 11). 1201 Closing the MASC connection (that results from the collision resolution 1202 procedure) is accomplished by sending the NOTIFICATION message with the 1203 Error Code Cease. 1205 10. MASC Version Negotiation 1207 MASC speakers may negotiate the version of the protocol by making 1208 multiple attempts to open a MASC connection, starting with the highest 1209 version number each supports. If an open attempt fails with an Error 1210 Code OPEN Message Error, and an Error Subcode Unsupported Version 1211 Number, then the MASC speaker has available the version number it tried, 1212 the version number the remote node tried, the version number passed by 1213 the remote node in the NOTIFICATION message, and the version numbers 1214 that it supports. If the two MASC speakers do support one or more 1215 common versions, then this will allow them to rapidly determine the 1216 highest common version. In order to support MASC version negotiation, 1217 future versions of MASC must retain the format of the OPEN and 1218 NOTIFICATION messages. 1220 11. MASC Finite State machine 1222 This section specifies MASC operation in terms of a Finite State Machine 1223 (FSM). Following is a brief summary and overview of MASC operations by 1224 state as determined by this FSM. 1226 Initially MASC is in the Idle state. 1228 Draft MASC August 1998 1230 11.1. Open/Close MASC Connection FSM 1232 Idle state: 1234 In this state MASC refuses all incoming MASC connections. No 1235 resources are allocated to the remote node. In response to the Start 1236 event (initiated by either system or operator) the local system 1237 initializes all MASC resources, starts the ConnectRetry timer, 1238 initiates a transport connection to the remote node, while listening 1239 for connection that may be initiated by the remote MASC node, and 1240 changes its state to Connect. The exact value of the ConnectRetry 1241 timer is a local matter, but should be sufficiently large to allow 1242 TCP initialization. 1244 If a MASC speaker detects an error, it shuts down the connection and 1245 changes its state to Idle. Getting out of the Idle state requires 1246 generation of the Start event. If such an event is generated 1247 automatically, then persistent MASC errors may result in persistent 1248 flapping of the speaker. To avoid such a condition it is recommended 1249 that Start events should not be generated immediately for a node that 1250 was previously transitioned to Idle due to an error. For a node that 1251 was previously transitioned to Idle due to an error, the time between 1252 consecutive generation of Start events, if such events are generated 1253 automatically, shall exponentially increase. The value of the initial 1254 timer shall be 60 seconds. The time shall be doubled for each 1255 consecutive retry. 1257 Any other event received in the Idle state is ignored. 1259 Connect state: 1261 In this state MASC is waiting for the transport protocol connection 1262 to be completed. 1264 If the transport protocol connection succeeds, the local system 1265 clears the ConnectRetry timer, completes initialization, sends an 1266 OPEN message to the remote node, and changes its state to OpenSent. 1267 If the transport protocol connect fails (e.g., retransmission 1268 timeout), the local system restarts the ConnectRetry timer, continues 1269 to listen for a connection that may be initiated by the remote MASC 1270 node, and changes its state to Active state. 1272 In response to the ConnectRetry timer expired event, the local system 1273 restarts the ConnectRetry timer, initiates a transport connection to 1274 other MASC node, continues to listen for a connection that may be 1276 Draft MASC August 1998 1278 initiated by the remote MASC node, and stays in the Connect state. 1280 The Start event is ignored in the Connect state. 1282 In response to any other event (initiated by either system or 1283 operator), the local system releases all MASC resources associated 1284 with this connection and changes its state to Idle. 1286 Active state: 1288 In this state MASC is trying to acquire a remote node by initiating a 1289 transport protocol connection. 1291 If the transport protocol connection succeeds, the local system 1292 clears the ConnectRetry timer, completes initialization, sends an 1293 OPEN message to the remote node, sets its Hold Timer to a large 1294 value, and changes its state to OpenSent. A Hold Timer value of 1295 [HOLDTIME] minutes is suggested. 1297 In response to the ConnectRetry timer expired event, the local system 1298 restarts the ConnectRetry timer, initiates a transport connection to 1299 other MASC node, continues to listen for a connection that may be 1300 initiated by the remote MASC node, and changes its state to Connect. 1302 If the local system detects that a remote node is trying to establish 1303 MASC connection to it, and the IP address of the remote node is not 1304 an expected one, the local system restarts the ConnectRetry timer, 1305 rejects the attempted connection, continues to listen for a 1306 connection that may be initiated by the remote MASC node, and stays 1307 in the Active state. 1309 The Start event is ignored in the Active state. 1311 In response to any other event (initiated by either system or 1312 operator), the local system releases all MASC resources associated 1313 with this connection and changes its state to Idle. 1315 OpenSent state: 1317 In this state MASC waits for an OPEN message from the remote node. 1318 When an OPEN message is received, all fields are checked for 1319 correctness. If the MASC message header checking or OPEN message 1320 checking detects an error (see Section 9.2), or a connection 1321 collision (see Section 9.8) the local system sends a NOTIFICATION 1322 message and, if the connection is to be closed, it changes its state 1324 Draft MASC August 1998 1326 to Idle. 1328 If the locally configured role is SIBLING and if there is no common 1329 Parent Domain ID between the local and the remote node (among the 1330 included in the OPEN message), the local system sends a NOTIFICATION 1331 Open Message Error with Error Subcode set to No Common Parent, the 1332 connection must be closed, and the state of the local system must be 1333 changed to Idle. 1335 If there are no errors in the OPEN message, MASC sends a KEEPALIVE 1336 message and sets a KeepAlive timer. The Hold Timer, which was 1337 originally set to a large value (see above), is replaced with the 1338 negotiated Hold Time value (see Section 8.2). If the negotiated Hold 1339 Time value is zero, then the Hold Time timer and KeepAlive timers are 1340 not started. If the value of the MASC Domain ID field is the same as 1341 the local Autonomous System number, and if the Role field of the OPEN 1342 message is set to INTERNAL_PEER, then the connection is an "internal" 1343 connection; otherwise, it is "external". Finally, the state is 1344 changed to OpenConfirm. 1346 If a disconnect notification is received from the underlying 1347 transport protocol, the local system closes the MASC connection, 1348 restarts the ConnectRetry timer, while continue listening for 1349 connection that may be initiated by the remote MASC node, and goes 1350 into the Active state. 1352 If the Hold Timer expires, the local system sends NOTIFICATION 1353 message with error code Hold Timer Expired and changes its state to 1354 Idle. 1356 In response to the Stop event (initiated by either system or 1357 operator) the local system sends NOTIFICATION message with Error Code 1358 Cease and changes its state to Idle. 1360 The Start event is ignored in the OpenSent state. 1362 In response to any other event the local system sends a NOTIFICATION 1363 message with Error Code Finite State Machine Error and Error Subcode 1364 Open/Close MASC Connection FSM Error, and changes its state to Idle. 1366 Whenever MASC changes its state from OpenSent to Idle, it closes the 1367 MASC (and transport-level) connection and releases all resources 1368 associated with that connection. 1370 OpenConfirm state: 1372 Draft MASC August 1998 1374 In this state MASC waits for a KEEPALIVE or NOTIFICATION message. 1376 If the local system receives a KEEPALIVE message, it changes its 1377 state to Established. 1379 If the Hold Timer expires before a KEEPALIVE message is received, the 1380 local system sends NOTIFICATION message with error code Hold Timer 1381 Expired and changes its state to Idle. 1383 If the local system receives a NOTIFICATION message with the C-bit 1384 set, it changes its state to Idle. 1386 If the KeepAlive timer expires, the local system sends a KEEPALIVE 1387 message and restarts its KeepAlive timer. 1389 If a disconnect notification is received from the underlying 1390 transport protocol, the local system changes its state to Idle. 1392 In response to the Stop event (initiated by either system or 1393 operator) the local system sends NOTIFICATION message with Error Code 1394 Cease and changes its state to Idle. 1396 The Start event is ignored in the OpenConfirm state. 1398 In response to any other event the local system sends a NOTIFICATION 1399 message with Error Code Finite State Machine Error and Error Subcode 1400 Unspecific, and changes its state to Idle. 1402 Whenever MASC changes its state from OpenConfirm to Idle, it closes 1403 the MASC (and transport-level) connection and releases all resources 1404 associated with that connection. 1406 Established state: 1408 In the Established state MASC can exchange UPDATE, NOTIFICATION, and 1409 KEEPALIVE messages with the remote node. 1411 If the local system receives an UPDATE or KEEPALIVE message, it 1412 restarts its Hold Timer, if the negotiated Hold Time value is non- 1413 zero. 1415 If the local system receives a NOTIFICATION message, with the C-bit 1416 set, it changes its state to Idle. 1418 If the local system receives an UPDATE message and the UPDATE message 1420 Draft MASC August 1998 1422 error handling procedure (see Section 9.3) detects an error, the 1423 local system sends a NOTIFICATION message and, if the C-bit was set, 1424 changes its state to Idle. 1426 If a disconnect notification is received from the underlying 1427 transport protocol, the local system changes its state to Idle. 1429 If the Hold Timer expires, the local system sends a NOTIFICATION 1430 message with Error Code Hold Timer Expired and changes its state to 1431 Idle. 1433 If the KeepAlive timer expires, the local system sends a KEEPALIVE 1434 message and restarts its KeepAlive timer. 1436 Each time the local system sends a KEEPALIVE or UPDATE message, it 1437 restarts its KeepAlive timer, unless the negotiated Hold Time value 1438 is zero. 1440 In response to the Stop event (initiated by either system or 1441 operator), the local system sends a NOTIFICATION message with Error 1442 Code Cease and changes its state to Idle. 1444 The Start event is ignored in the Established state. 1446 After entering the Established state, if the local system has UPDATE 1447 messages that are to be sent to the remote node, they must be sent 1448 immediately. 1450 In response to any other event, the local system sends NOTIFICATION 1451 message with Error Code Finite State Machine Error with the C-bit set 1452 and Error Subcode Unspecific, and changes its state to Idle. 1454 Whenever MASC changes its state from Established to Idle, it closes 1455 the MASC (and transport-level) connection, releases all resources 1456 associated with that connection, and deletes all state derived from 1457 that connection. 1459 12. UPDATE Message Processing 1461 The UPDATE message are accepted only when the system is in the 1462 Established state. 1464 In the text below, a MASC domain is considered a child of itself with 1465 regard to the claims that are related to the address space with local 1466 Draft MASC August 1998 1468 usage purpose (i.e. to be used by the MAASs within that domain). For 1469 example, a NEW_CLAIM initiated by a MASC node to obtain more space for 1470 local usage from a prefix managed by that domain will have field Role = 1471 CHILD. 1473 If an UPDATE is to be propagated further, it should not be sent back to 1474 the node that UPDATE was received from, unless there is an indication 1475 that the connection to that node was down and then restored. 1477 If the local system receives an UPDATE message, and there is no 1478 indication for error, the following actions are taken: 1480 1. Accept/reject the UPDATE 1481 The Origin Role field is first compared against the local system's 1482 configured Role, according to Table 1, to determine the relationship 1483 of the origin to the local system. A result of "---" means that 1484 receiving such an UPDATE is illegal and should generate a 1485 NOTIFICATION. Any other result is the value to use as the "Updated" 1486 Origin Role when propagating the UPDATE to others. (This is 1487 analogous to updating a metric upon receiving a route, based on the 1488 metric of the link.) 1490 Locally-Configured Role 1491 Origin 1492 Role | INTERNAL_PEER | CHILD | SIBLING | PARENT 1493 ---------+---------------+---------+---------+--------- 1494 INTERNAL | INTERNAL_PEER | PARENT | SIBLING | CHILD 1495 CHILD | CHILD | SIBLING | --- | --- 1496 SIBLING | SIBLING | --- | SIBLING | CHILD 1497 PARENT | PARENT | --- | PARENT | --- 1499 Table 1: Updated Origin Role Computation 1501 If the output from the Updated Origin Role Computation is SIBLING, 1502 but the Origin Domain ID is the same as the local MASC domain, the 1503 Updated Origin Role is changed to INTERNAL. This is necessary in 1504 case a MASC node receives from a parent or sibling its own UPDATEs 1505 after reboot, or if because of internal partitioning, the 1506 INTERNAL_PEERs are exchanging UPDATEs via other MASC domains (either 1507 parent or sibling(s)). 1509 If Claim Timestamp and Claim Holdtime indicate that the claim has 1510 expired (e.g. Timestamp + Claim Holdtime <= CurrentTime), the UPDATE 1511 is silently dropped and no further actions are taken. 1513 Draft MASC August 1998 1515 Each new arrival UPDATE is compared with all claims in the local 1516 cache. The following fields are compared, and if all of them are the 1517 same, the message is silently rejected and no further actions are 1518 taken: 1520 o A-bit, Role, Type 1522 o AddrFam 1524 o Origin Domain Identifier 1526 o Origin Node Identifier 1528 o Claim Timestamp 1530 o Claim Lifetime 1532 o Claim Holdtime 1534 o Address 1536 o Mask 1538 2. PREFIX_IN_USE message processing 1540 o If the Updated Origin Role is PARENT, the claim is rejected, and a 1541 NOTIFICATION with Error Code UPDATE Message Error and Error Subcode 1542 Illegal Origin Role should be sent back. 1544 o If the Updated Origin Role is SIBLING, and the claim collides with 1545 some of the local domain's pending claims, the loser claims must 1546 not be considered further, and the Claim-Timer of each of them must 1547 be canceled. If the received PREFIX_IN_USE claim clashes with and 1548 wins over from some of the local domain's allocated prefixes, 1549 resolve the clash according to Section 13.1. Finally, the claim 1550 must be propagated further to all INTERNAL_PEERs, all MASC nodes 1551 from the corresponding parent MASC domain and all known siblings of 1552 the same parent domain. 1554 o If the Updated Origin Role is CHILD, the received claim must be 1555 propagated further to all INTERNAL_PEERs and all MASC children 1556 domains. 1558 o If the Updated Origin Role is INTERNAL_PEER, but the Origin Domain 1559 ID differs from the local Domain ID, a NOTIFICATION with Error Code 1561 Draft MASC August 1998 1563 UPDATE Message Error and Error Subcode Illegal Origin Role must be 1564 sent back, and the claim is rejected. If the MASC node decides that 1565 the local domain does not need anymore that prefix, it must be 1566 withdrawn, otherwise, the claim is processed as PREFIX_MANAGED. 1568 3. CLAIM_DENIED message processing 1570 o If the Updated Origin Role is CHILD or SIBLING, the message is 1571 rejected, and a NOTIFICATION with Error Code UPDATE Message Error 1572 and Error Subcode Illegal Origin Role should be sent back. 1574 o If the Updated Origin Role is INTERNAL_PEER, propagate to all other 1575 INTERNAL_PEERs, and all MASC children nodes that have same Domain 1576 ID as Origin Domain ID in the received CLAIM_DENIED message. 1578 o If the Updated Origin Role is PARENT, propagate to all other 1579 INTERNAL_PEERs. If there is a corresponding pending claim 1580 originated by the local MASC domain (i.e. a NEW_CLAIM or 1581 CLAIM_TO_EXPAND with same AddrFam, Origin Domain ID, Claim 1582 Timestamp, Address and Mask), its Claim-Timer must be cancel and 1583 the claim must not be considered further. 1585 4. CLAIM_TO_EXPAND message processing 1587 o If the Updated Origin Role is PARENT, the claim is rejected, and a 1588 NOTIFICATION with Error Code UPDATE Message Error and Error Subcode 1589 Illegal Origin Role should be sent back. 1591 o If the Updated Origin Role is SIBLING and if the received 1592 CLAIM_TO_EXPAND collides with and wins over some of the local 1593 domain's pending claims, the loser claims must not be considered 1594 further, and the Claim-Timer of the each of them must be cancel. 1595 Also, the received claim must be propagated further to all 1596 INTERNAL_PEERs, all MASC nodes from the same parent MASC domain and 1597 all known siblings of the same parent domain. 1599 o If the Updated Origin Role is CHILD, propagate the claim to all 1600 INTERNAL_PEERs. If the claimed prefix is not managed by the local 1601 domain, or if the lifetime of the claim is longer than the lifetime 1602 of the corresponding prefix managed by the local domain, or if the 1603 corresponding prefix managed by the local domain is deprecated, or 1604 there is an administratively configured reason to prevent the 1605 child from succeeding allocating the claimed prefix, a CLAIM_DENIED 1606 must be send to all MASC children nodes that have same Domain ID as 1607 Origin Domain ID in the received CLAIM_TO_EXPAND message. The 1609 Draft MASC August 1998 1611 CLAIM_DENIED must be the same as the received claim, except 1612 Rol=INTERNAL, and Claim Lifetime should be set to the maximum 1613 allowed lifetime. Otherwise, propagate the claim to all children 1614 as well. 1616 o If the Updated Origin Role is INTERNAL_PEER, but the Origin Domain 1617 ID differs from the local Domain ID, a NOTIFICATION with Error Code 1618 UPDATE Message Error and Error Subcode Illegal Origin Role must be 1619 sent back, and the claim is rejected. If the MASC node decides 1620 that the local domain does not need anymore that pending claim, it 1621 MAY be withdrawn. Otherwise, the claim must be propagated to all 1622 INTERNAL_PEERs and all MASC nodes from the parent MASC domain that 1623 has advertised PREFIX_MANAGED that covers the claimed prefix. 1625 5. NEW_CLAIM message processing 1627 Process like CLAIM_TO_EXPAND. 1629 6. PREFIX_MANAGED message processing. 1631 o If the Updated Origin Role is SIBLING or CHILD, the message is 1632 rejected, and a NOTIFICATION with Error Code UPDATE Message Error 1633 and Error Subcode Illegal Origin Role should be sent back. 1635 o If the Updated Origin Role is PARENT, and if it matches one of the 1636 parents' domain ID, the prefix is recorded and can be used by the 1637 address allocation algorithm for allocating subranges. Also, the 1638 message is propagated to all INTERNAL_PEERs. 1640 o If the Updated Origin Role is INTERNAL_PEER, the prefix is recorded 1641 as allocated to the local domain, propagated to all INTERNAL_PEERs, 1642 and can be used for (all items apply): 1644 a) address ranges/prefixes advertisements to all MASC children and 1645 local domain's MAASs; 1647 b) injection into G-RIB; 1649 c) further expansion by the address allocation algorithm (see 1650 Appendix A); If the Updated Origin Role is INTERNAL_PEER and if 1651 there is already in the local cache a WITHDRAW message that 1652 overlaps with the received PREFIX_MANAGED, the range of that 1653 WITHDRAW cannot be used for advertisements to the local domain's 1654 MAASs [AAP] and for injection into G-RIB. In the special case 1655 when there is an indication that the WITHDRAW has being 1657 Draft MASC August 1998 1659 originated by the local domain because of a clash, and the range 1660 specified in WITHDRAW is a subrange of PREFIX_MANAGED, and the 1661 Claim Holdtime of WITHDRAW is shorter than the Claim Holdtime of 1662 PREFIX_MANAGED, the WITHDRAW's range should not be withdrawn 1663 from G-RIB. 1665 7. WITHDRAW message processing 1667 o If the Updated Origin Role is CHILD, propagate to all 1668 INTERNAL_PEERs and children. 1670 o If the Updated Origin Role is SIBLING, propagate to all 1671 INTERNAL_PEERs, all MASC nodes from the same parent MASC domain and 1672 all known siblings of the same parent domain. 1674 o If the Updated Origin Role is INTERNAL, propagate to all 1675 INTERNAL_PEERs, all MASC nodes of the parent domain that manages 1676 the corresponding parent's space, all known siblings of that parent 1677 domain and all children. If there are overlapping PREFIX_MANAGED 1678 or PREFIX_IN_USE originated/owned by the local MASC domain, stop 1679 advertising the WITHDRAW range to the MAASs and withdraw that range 1680 from the G-RIB database. In the special case when there is an 1681 indication that the WITHDRAW has being originated by the local 1682 domain because of clash, and the range specified in WITHDRAW is a 1683 subrange of PREFIX_MANAGED, and the Claim Holdtime of WITHDRAW is 1684 shorter than the Claim Holdtime of PREFIX_MANAGED, the WITHDRAW's 1685 range should not be withdrawn from G-RIB. 1687 o If the Updated Origin Role is PARENT, propagate to all 1688 INTERNAL_PEERs and all known siblings of the same parent domain. 1689 Finally, originate a WITHDRAW message for each intersection of a 1690 locally owned PREFIX_MANAGED/PREFIX_IN_USE and the received 1691 WITHDRAW. The locally originated WITHDRAW message's Claim Holdtime 1692 should be equal to the received from the parent's WITHDRAW Claim 1693 Holdtime; the Origin Node ID should be the same as the particular 1694 PREFIX_MANAGED/PREFIX_IN_USE. 1696 13. Operational Considerations 1698 13.1. Clash Resolving Mechanism 1700 If a MASC node receives a PREFIX_IN_USE claim originated by a sibling 1701 and the claim overlaps with some of the local prefixes, the clash must 1702 Draft MASC August 1998 1704 be resolved. Two MASC domains should not manage overlapping address 1705 ranges, unless the domains have an ancestor-descendant (e.g. parent- 1706 child) relationship in the MASC hierarchy. Also, two MASC domains 1707 should not have locally-allocated overlapping address ranges. The 1708 clashed address ranges should not be advertised to the MAASs and 1709 allocated to multicast applications/sessions. If a clashed address has 1710 being allocated to an application, the application should be informed to 1711 stop using that address and switch to a new one. 1713 The G-RIB database must be consistent, such that it does not have 1714 ambiguous entries. "Ambiguous G-RIB entries" are those entries that 1715 might cause the multicast routing protocol to loop or lose connectivity. 1716 In MASC the WITHDRAW message is used to solve this problem. When a 1717 clashing PREFIX_IN_USE is received, it is compared (using the function 1718 describe in Section 6.1.1) against all prefixes allocated to the local 1719 domain. If the local PREFIX_IN_USE is the winner, no further actions 1720 are taken. If the local PREFIX_IN_USE is the loser, the clashing 1721 address range must be withdrawn by initiating a WITHDRAW message. The 1722 message must have Role = INTERNAL, Origin Node ID and Origin Domain ID 1723 must be the same as the corresponding local PREFIX_IN_USE message, while 1724 Claim Timestamp, Claim Lifetime, Claim Holdtime, Address and Mask must 1725 be the same as the received winning PREFIX_IN_USE. The initiated 1726 WITHDRAW message must be processed as described in Section 12.7. 1728 If a cached WITHDRAW times out and the local MASC domain owns an 1729 overlapping PREFIX_MANAGED or PREFIX_IN_USE, the overlapping PREFIX 1730 ranges can be injected back into the G-RIB database. Similarly, the 1731 address ranges that were not advertised to the local domain's MAASs due 1732 to the WITHDRAW, can now be advertised again. 1734 In addition to the automatic resolving of clashes, a MASC implementation 1735 should support manual resolving of clashes. For example, after a clash 1736 is detected, the network administrator should be informed that a clash 1737 has occured. The specific manual mechanisms are outside the scope of 1738 this protocol. 1740 A MASC node must be configured to operate using either manual or 1741 automatic clash resolution mechanisms. 1743 13.2. Changing network providers 1745 If a MASC domain changes a network provider, such that the old provider 1746 cannot be used to provide connectivity, any traffic for sessions that 1747 are in progress and use that MASC domain as a BGMP Root Domain will not 1748 Draft MASC August 1998 1750 be able to reach that domain. 1752 If the new network provider is willing to carry the traffic for the old 1753 sessions rooted at the customer domain, then it must propagate the 1754 customer's old prefixes through the G-RIB. However, at least one MASC 1755 node in the customer domain must maintain a TCP connection to one of the 1756 old network provider's MASC nodes. Thus, it can continue to "defend" 1757 the customer's prefixes, and should continue until the old prefixes' 1758 lifetimes expire. 1760 If the new network provider is not willing to propagate the old 1761 prefixes, then the customer should remove its prefixes from the G-RIB. 1762 If BGMP is in use, the old network provider's domain will automatically 1763 become the Root Domain for the customer's old groups due to the lack of 1764 a more specific group route. MASC nodes in the customer domain MAY 1765 still connect with the old provider's MASC nodes to defend their 1766 allocation. 1768 13.3. Debugging 1770 13.3.1. Prefix-to-domain lookup 1772 Use mtrace [MTRACE] to find the BGMP/MASC root domain for a group 1773 address chosen from that prefix. 1775 13.3.2. Domain-to-prefix lookup 1777 We can find the address space allocated to a particular MASC domain by 1778 directly quering one of the MASC servers within that domain. TODO: How 1779 to find the address of one of the MASC nodes within a particular domain? 1780 Find some of the BGMP routers there, but how? 1782 14. MASC storage 1784 In general, MASC will be run by a border routers, which, in general do 1785 not have stable storage. In this case, MASC must use AAP ([AAP]) to 1786 store the important information (the prefixes allocated by the local 1787 domain) in the domain's MAASs who should have stable storage. If the 1788 MASC/BGMP router has local storage, it should use it instead of AAP. 1789 Claims that are in progress do not have to be saved by using AAP. 1791 Draft MASC August 1998 1793 15. Security Considerations 1795 TODO 1797 16. Open Issues 1799 o MASC port number 1801 o Startup and reading from MAASs, initial delay for waiting, FSM, etc. 1803 Draft MASC August 1998 1805 17. APPENDIX A: Sample algorithms 1807 DISCLAIMER: This section describes some preliminary suggestions by 1808 various people for algorithms which could be used with MASC. They are 1809 mentioned here merely to stimulate discussion, and are not to be taken 1810 as a specification. 1812 17.1. Start-up rules 1814 17.1.1. Top-Level Domains and Global Space Injectors 1816 All TLDs are siblings of each other and share the same space. Unlike the 1817 rest of the hierarchy, TLDs do not have explicit parent(s); instead, 1818 flooding the TLD mesh is used to propagate the claims. However, one or 1819 few "space injectors" are necessary to replace some of the functions of 1820 the MASC parents. These "injectors" initiate the advertisement of the 1821 globally available address space to the TLDs. If the prefix 225/8 (for 1822 example) were designated as globally allocatable at a given exchange, 1823 then the space injectors at that exchange would inject 225/8 as a 1824 PREFIX_MANAGED into the TLDs mesh. These advertisements would have a 1825 very long lifetime, of the order of at least 6 (TODO) months. The 1826 injectors should periodically renew the lifetime of the advertised 1827 global space. If for some reason some address range that is part of the 1828 global address space should not longer be globally allocated, then the 1829 space injectors will: 1831 a) stop re-expanding the lifetime of that address range, AND 1833 b) advertise that address range as non-active for the rest of its 1834 lifetime. 1836 The global address space advertised by Global Space Injectors must be 1837 chosen by IANA (TODO). 1839 17.1.2. Default initial claim size 1841 The default initial claim size is 256 addresses. 1843 One alternate suggestion was to claim a number of addresses equal to 1844 1/16th the domain's unicast address space. However, this may be 1845 problematic since multicast space usage may not mirror unicast usage, 1846 and claiming a large amount of multicast space without adequate demand 1847 could cause enormous wastage. Instead, better performance results from 1848 Draft MASC August 1998 1850 demand-driven claims, and hence a fixed initial claim size is suggested 1851 instead, with claims being expanded as needed due to demand. 1853 If the MASC server has been running in the past, and if it has saved 1854 information about the demand pattern, that information should be used to 1855 decide the default initial claim size. 1857 17.1.3. Default initial claim lifetime 1859 The default initial claim lifetime is 30 (TODO) days. 1861 If there is information available from the past, or if claims from the 1862 children MASC domains have been received, the longest appropriate 1863 lifetime should be used instead of the default 30 days. 1865 17.2. Claim Size and Prefix Selection Algorithm 1867 TODO 1869 17.2.1. Prefix expansion 1871 TODO 1873 17.2.2. Address space utilization 1875 TODO 1877 17.2.3. Prefix selection after increase of demand 1879 TODO 1881 17.2.4. Prefix selection after decrease of demand 1883 TODO 1885 17.2.5. Lifetime extension algorithm 1887 TODO 1888 Draft MASC August 1998 1890 18. Authors' Addresses 1892 Deborah Estrin 1893 Computer Science Department/ISI 1894 University of Southern California 1895 Los Angeles, CA 90089 1896 USA 1897 Email: estrin@usc.edu 1899 Ramesh Govindan 1900 USC/ISI 1901 4676 Admiralty Way 1902 Marina Del Rey, CA 90292 1903 USA 1904 Email: govindan@isi.edu 1906 Mark Handley 1907 USC/ISI 1908 c/o MIT LCS 1909 545 Technology Square 1910 Cambridge, MA 02141 1911 USA 1912 Email: mjh@isi.edu 1914 Satish Kumar 1915 Computer Science Department/ISI 1916 University of Southern California 1917 Los Angeles, CA 90089 1918 USA 1919 Email: kkumar@usc.edu 1921 Pavlin Ivanov Radoslavov 1922 Computer Science Department/ISI 1923 University of Southern California 1924 Los Angeles, CA 90089 1925 USA 1926 Email: pavlin@catarina.usc.edu 1928 David Thaler 1929 Microsoft 1930 One Microsoft Way 1931 Redmond, WA 98052 1932 USA 1933 Email: dthaler@microsoft.com 1935 Draft MASC August 1998 1937 19. References 1939 [AAP] 1940 Handley, M., "Multicast Address Allocation Protocol (AAP)", 1941 http://north.east.isi.edu/malloc/aap-01.txt July 1998. 1943 [API] 1944 Finlayson, Ross, "An Abstract API for Multicast Address 1945 Allocation", draft-ietf-malloc-api-01.txt, July 1998. 1947 [BGMP] 1948 Thaler, D., Estrin, D. and D. Meyer., "Border Gateway Multicast 1949 Protocol (BGMP): Protocol Specification", draft-ietf-idmr-gum- 1950 02.txt, March 1998. 1952 [BGP] 1953 Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1954 1771, March 1995. 1956 [IANA] 1957 Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1958 1994. 1960 [MALLOC] 1961 Handley, M., Thaler, D. and D. Estrin, "The Internet Multicast 1962 Address Allocation Architecture", draft-handley-malloc-arch-00.txt, 1963 December 1997. 1965 [MBGP] 1966 Bates, T., Chandra, R., Katz, D., and Y. Rekhter., "Multiprotocol 1967 Extensions for BGP-4", RFC 2283, September 1997. 1969 [MTRACE] 1970 Fenner, W., and S. Casner, "A ''traceroute'' facility for IP 1971 Multicast", draft-ietf-idmr-traceroute-ipm-02.txt, November 1997. 1973 [MZAP] 1974 Handley, M, "Multicast-Scope Zone Announcement Protocol", draft- 1975 ietf-mboned-mzap-00.txt, December 1997. 1977 [SCOPE] 1978 Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1979 1998. 1981 Draft MASC August 1998 1983 20. Full Copyright Statement 1985 Copyright (C) The Internet Society (1998). All Rights Reserved. 1987 This document and translations of it may be copied and furnished to 1988 others, and derivative works that comment on or otherwise explain it or 1989 assist in its implementation may be prepared, copied, published and 1990 distributed, in whole or in part, without restriction of any kind, 1991 provided that the above copyright notice and this paragraph are included 1992 on all such copies and derivative works. However, this document itself 1993 may not be modified in any way, such as by removing the copyright notice 1994 or references to the Internet Society or other Internet organizations, 1995 except as needed for the purpose of developing Internet standards in 1996 which case the procedures for copyrights defined in the Internet 1997 Standards process must be followed, or as required to translate it into 1998 languages other than English. 2000 The limited permissions granted above are perpetual and will not be 2001 revoked by the Internet Society or its successors or assigns. 2003 This document and the information contained herein is provided on an "AS 2004 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2005 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2006 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2007 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2008 FITNESS FOR A PARTICULAR PURPOSE." 2010 Table of Contents 2012 1 Introduction .................................................... 2 2013 2 Requirements for Inter-Domain Address Allocation ................ 2 2014 3 Overall Architecture ............................................ 3 2015 3.1 Claim-collide vs. query-response rationale .................... 3 2016 4 MASC Topology ................................................... 4 2017 5 Address Space Structure ......................................... 6 2018 5.1 Managed vs Locally-Allocated Space ............................ 6 2019 5.2 Prefix lifetimes .............................................. 6 2020 5.3 Active vs. deprecated prefixes ................................ 6 2021 5.4 Administratively-Scoped Address Allocation .................... 7 2022 6 Protocol Details ................................................ 8 2023 6.1 Claiming Space ................................................ 8 2024 6.1.1 Claim Comparison Function ................................... 10 2025 6.2 Renewing an Existing Claim .................................... 10 2026 Draft MASC August 1998 2028 6.3 Expanding an Existing Prefix .................................. 10 2029 6.4 Releasing Allocated Space ..................................... 11 2030 7 Constants ....................................................... 11 2031 8 Message Formats ................................................. 11 2032 8.1 Message Header Format ......................................... 12 2033 8.2 OPEN Message Format ........................................... 13 2034 8.3 UPDATE Message Format ......................................... 16 2035 8.4 KEEPALIVE Message Format ...................................... 18 2036 8.5 NOTIFICATION Message Format ................................... 19 2037 9 MASC Error Handling ............................................. 22 2038 9.1 Message Header error handling ................................. 22 2039 9.2 OPEN message error handling ................................... 22 2040 9.3 UPDATE message error handling ................................. 24 2041 9.4 Hold Timer Expired error handling ............................. 26 2042 9.5 Finite State Machine error handling ........................... 26 2043 9.6 NOTIFICATION message error handling ........................... 26 2044 9.7 Cease ......................................................... 27 2045 9.8 Connection Collision Detection ................................ 27 2046 10 MASC Version Negotiation ....................................... 28 2047 11 MASC Finite State machine ...................................... 28 2048 11.1 Open/Close MASC Connection FSM ............................... 29 2049 12 UPDATE Message Processing ...................................... 33 2050 13 Operational Considerations ..................................... 38 2051 13.1 Clash Resolving Mechanism .................................... 38 2052 13.2 Changing network providers ................................... 39 2053 13.3 Debugging .................................................... 40 2054 13.3.1 Prefix-to-domain lookup .................................... 40 2055 13.3.2 Domain-to-prefix lookup .................................... 40 2056 14 MASC storage ................................................... 40 2057 15 Security Considerations ........................................ 41 2058 16 Open Issues .................................................... 41 2059 17 APPENDIX A: Sample algorithms .................................. 42 2060 17.1 Start-up rules ............................................... 42 2061 17.1.1 Top-Level Domains and Global Space Injectors ............... 42 2062 17.1.2 Default initial claim size ................................. 42 2063 17.1.3 Default initial claim lifetime ............................. 43 2064 17.2 Claim Size and Prefix Selection Algorithm .................... 43 2065 17.2.1 Prefix expansion ........................................... 43 2066 17.2.2 Address space utilization .................................. 43 2067 17.2.3 Prefix selection after increase of demand .................. 43 2068 17.2.4 Prefix selection after decrease of demand .................. 43 2069 17.2.5 Lifetime extension algorithm ............................... 43 2070 18 Authors' Addresses ............................................. 44 2071 19 References ..................................................... 45 2072 20 Full Copyright Statement ....................................... 46 2073 Draft MASC August 1998