idnits 2.17.1 draft-retana-marp-02.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: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (March 2003) is 7713 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'FLIP' -- Possible downref: Normative reference to a draft: ref. 'PLP' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alvaro Retana 3 Internet Draft Russ White 4 Expiration Date: September 2003 Cisco Systems, Inc. 5 File Name: draft-retana-marp-02.txt March 2003 7 MultiAccess Reachability Protocol (MARP) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its Areas, and its Working Groups. Note that other 16 groups may also distribute working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http//www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http//www.ietf.org/shadow.html. 30 Abstract 32 This document defines a protocol to quickly determine the existence 33 or aliveness of devices attached to a shared media (broadcast) 34 subnet. While the examples used are narrowly defined for simplicity, 35 the protocol could be applied to other situations as well. 37 1. Specification of Requirements 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in [RFC2119]. 43 2. Motivation 45 There is a great deal of interest in discovering when a device drops 46 off of a broadcast (shared) media link for various purposes, not 47 limited to: 49 o Loss of routing protocol neighbors. Routing protocols would like 50 to discover the loss of a neighbor as quickly as possible so 51 they can reconverge around the topology change, dropping as lit- 52 tle traffic as possible. 54 o Loss of a server. If multiple servers, offering the same ser- 55 vice, exist on a segment, a device which is load balancing 56 traffic between those servers would like to know as soon as one 57 of them fails. 59 Towards this end, several solutions ([ISIS_SHORT], [LSP_PING], [FLIP] 60 and [PLP], for example) have been designed, most (or all) of which 61 rely on some sort of "fast aliveness" or "fast hello" protocol to 62 quickly determine the failure of a node on a shared media segment. 63 There is some question about the scalability of such protocols, since 64 there could be hundreds of devices on a single high speed broadcast 65 network, and a single device could be connected to hundreds of broad- 66 cast networks. 68 Most devices in today's networks are not connected to a true broacast 69 segment (such as a 10base5 coax cable), but are instead connected to 70 a layer 2 switch (using point-to-point connections) that can deter- 71 mine if a device is still alive based on the carrier detect circuitry 72 at the physical or data link layers. It should be possible to somehow 73 harness this immediate and constant status information to inform 74 other network devices about state changes for a particular device. 76 This document defines the MultiAccess Reachability Protocol (MARP), 77 which allows for the fast notification of loss of connectivity to 78 devices attached to a shared media (broadcast) subnet. 80 3. MARP Packet Format 82 MARP runs directly over layer 2. The data portion of the packet con- 83 sists of a header and TLVs as described in this section. 85 3.1. The MARP Header 87 The header, as well as all the other components, is simplified as 88 much as possible to keep the protocol light weight. 90 0 1 2 3 91 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 92 +---------------+---------------+---------------+---------------+ 93 | L2 Sub-Type | Version | Length | 94 +---------------+---------------+---------------+---------------+ 96 o L2 Sub-Type (1 octet): reserved field for use if the underly- 97 ing layer 2 media requires it. Otherwise, it SHOULD be sent 98 as 0 and ignored by the receiver. 100 o Version (1 octet): the version of the protocol; current value 101 is 1. 103 o Length (2 octets): total length of the MARP packet in octets. 105 3.2. The Authentication TLV 107 The Authentication TLV is used to optionally provide authentication 108 information to the receiver. 110 0 1 2 3 111 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 112 +---------------+---------------+---------------+---------------+ 113 | Type | Length | Auth Type | Reserved | 114 +---------------+---------------+---------------+---------------+ 115 | Authentication String... | 116 +---------------+---------------+---------------+---------------+ 118 o Type (1 octet): the type of the TLV. The Authentication TLV 119 has a type of 1. 121 o Length (1 octet): the total length of the TLV in octets. 123 o Authentication Type (1 octet): an unsigned integer indicating 124 the type of authentication present (described below). 126 o Reserved (1 octet): reserved for future use; SHOULD be sent 127 as 0 and ignored by the receiver. 129 o Authentication String (variable length): contains the authen- 130 tication information. 132 The Authentication Type field serves to indicate what type of authen- 133 tication is present, as well as its length. 135 0 Reserved, it MUST NOT be used. 137 1 Plain text authentication included (authentication string is 16 138 octets). 140 2 MD5 [MD5] authentication included (authentication string is 16 141 octets). 143 3.3. The Reachability Notification TLV 145 The Reachability Notification TLV is used to provide information 146 about the need for monitoring and the reachability of an address. 147 Details are provided in the "MARP Operation" section. 149 0 1 2 3 150 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 151 +---------------+---------------+---------------+---------------+ 152 | Type | Length | Reserved | 153 +---------------+---------------+---------------+---------------+ 154 | Opcode | Hold | 155 +---------------+---------------+---------------+---------------+ 156 | Hold-down | Address Length| Reserved | 157 +---------------+---------------+---------------+---------------+ 158 | Address.... | 159 +---------------+---------------+---------------+---------------+ 161 o Type (1 octet): the type of the TLV. The Reachability Notif- 162 ication TLV has a type of 2. 164 o Length (1 octet): the total length of the TLV in octets. 166 o Opcode (2 octets): A bit field containing information about 167 how the packet should be handled (described below). 169 o Hold (2 octets): the number of minutes the receiving device 170 should track the list of addresses included in the packet; 171 note that the hold time of any given entry need not match the 172 hold time of any other entry on the network. 174 o Hold-down (1 octet): the time in seconds a port which loses 175 connectivity to the addresses listed in the packet should be 176 held in the down state. The default value is 5 sec. 178 o Address Length (1 octet): length in octets of each address 179 included in this TLV. 181 o Address (variable length - more than one field may be present 182 in a packet): each field contains one address. The format of 183 the address depends on the underlying media. 185 o Reserved: reserved for future use; SHOULD be sent as 0 and 186 ignored by the receiver. 188 The Opcode field is used to determine how the TLV should be processed 189 when it is received. 191 o If the high order bit of this field is set, then the remaining 192 15 bits are vendor implementation specific. 194 o If the high order bit of this field is not set, then the two low 195 order bits indicate the message type: 197 00 UPDATE: MARP servers SHOULD provide notification when 198 reachability to the address(es) listed fails. A MARP 199 server may have an upper limit to the number of addresses 200 it can track, but this limit SHOULD NOT be lower than 100 201 per broadcast domain. 203 01 NOTIFY_HARD: Reachability to the address(es) listed has 204 failed. 206 10 NOTIFY_SOFT: Reachability to the address(es) listed may 207 have failed. 209 11 NACK: The address(es) listed cannot be tracked by a MARP 210 server at this time. 212 3.4. The Fast Reachability Verification TLV 214 As its name suggests, the Fast Reachability Verification TLV is used 215 to verify the reachability of a node. Details are provided in the 216 "MARP Operation" section. 218 In order to guarantee a fast response, this TLV SHOULD be the only 219 one present in the MARP packet. 221 0 1 2 3 222 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 223 +---------------+---------------+---------------+---------------+ 224 | Type | Opcode | Data | 225 +---------------+---------------+---------------+---------------+ 227 o Type (1 octet): the type of the TLV. The Fast Reachability 228 Verification TLV has a type of 3. 230 o Opcode (1 octet): A bit field containing information about 231 how the packet should be handled (described below). 233 o Data (2 octets): User defined data. 235 The Opcode field is used to determine how the TLV should be processed 236 when it is received. 238 o If the high order bit of this field is set, then the remaining 7 239 bits are vendor implementation specific. 241 o If the high order bit of this field is not set, then the low 242 order bit indicates the message type: 244 0 Fast Reachability Verification Detection (FRD): the 245 receiver MUST send the message back to the sender, indicat- 246 ing that it is now a Fast Reachability Verification Reply 247 message and including a logical NOT of the information in 248 the Data field. 250 1 Fast Reachability Verification Reply (FRR): used to reply 251 when an FRD is received. 253 4. MARP Operation 255 As described in this document, MARP can provide two basic services: 256 reachability notification and fast reachability verification. These 257 services are described in the following sections. 259 4.1. Reachability Notification 261 Reachability notification represents MARP's core service. In gen- 262 eral, the service consists in a device (MARP server) notifying a 263 group of other devices (MARP clients) about the loss in reachability 264 of another device (identified by an "interesting" address). 266 Two sub-sections follow to discuss the operation within a MARP 267 client, and then a MARP server. Note that a single device MAY be a 268 MARP server and a MARP client at the same time. 270 4.1.1. MARP Client Operation 272 A MARP client is a network device that wants to receive a notifica- 273 tion when a peer (such as a routing protocol neighbor, for example) 274 is no longer reachable. The operation is as follows: 276 o The MARP client compiles a list of "interesting" addresses 277 (these addresses MUST be significant to the underlying media) 278 that correspond to its peers. The MARP client's own address MAY 279 be part of the list. 281 o The list of "interesting" addresses is advertised using the 282 Reachability Notification TLV with an UPDATE Opcode. 284 o If a NACK message is received, the MARP client MAY use the pro- 285 cess defined in the "Fast Reachability Verification" section to 286 temporarily verify the reachability of any address(es) that the 287 MARP server cannot service at the time. 289 o An UPDATE message MUST be resent before the Hold Time expires. 290 If a received UPDATE message includes some (or all) of the 291 locally "interesting" addresses, then the Hold Time should be 292 locally reset to prevent the transmission of unnecessary 293 UPDATEs. On the other hand, to avoid the possible effects of a 294 lost UPDATE, they SHOULD be resent at least twice within the 295 Hold Time. 297 o A MARP client that receives a NOTIFY_HARD or NOTIFY_SOFT message 298 MAY use this information to reset known adjacencies, check adja- 299 cency status, or take other action as deemed appropriate 300 locally. 302 o If a NOTIFY_SOFT message is received, the MARP client MAY want 303 to verify the reachability of its peer before taking an action. 304 To do so, the process defined in the "Fast Reachability Verifi- 305 cation" section MAY be followed. 307 All the messages described in this section MUST be sent to a well- 308 known multicast address specific to the undelying media. 310 4.1.2. MARP Server Operation 312 A MARP server is a network device capable of tracking the reachabil- 313 ity of devices (including itself) on the same broadcast domain. The 314 operation is as follows: 316 o If an UPDATE message is received, and the request cannot be ser- 317 viced at the time (because the MARP server reached its internal 318 limit to the number of addresses it can track, for example), 319 then a NACK MUST be sent immediately in response. If the 320 request can be serviced, then for each address a MARP server 321 MUST determine whether it has reachability to it. 323 o If the address is found to not be reachable, then it should 324 be silently ignored. 326 o If the address is found to be reachable, then the Hold Time 327 MUST be set to the maximum of the current value or the time 328 specified in the message. The Hold-down Time MUST be set to 329 the maximum of the current value or the time specified in 330 the message. 332 o A MARP server MUST stop tracking any layer 2 addresses listed in 333 a NOTIFY_HARD packet. 335 o A MARP server SHOULD ignore any NOTIFY_SOFT packets. 337 o If a MARP server detects loss of connectivity to an address it 338 is tracking (and the Hold Time has not expired), it MUST send a 339 notification message (NOTIFY_HARD or NOTIFY_SOFT according to 340 the local configuration). If the loss of connectivity was due 341 to a port failure (physical or logical), then the corresponding 342 port SHOULD be maintained in the down state for the length of 343 the corresponding Hold-down Time. 345 In conjunction with processing the messges as described, the MARP 346 server SHOULD, if applicable, also forward them according to the 347 local multicast forwarding rules. 349 4.2. Fast Reachability Verification 351 Fast reachability verification in an optional MARP service that uses 352 the Fast Reachability Verification TLV. It can be used by a MARP 353 client to verify the reachability of a peer after a NOTIFY_SOFT mes- 354 sage is received or as a general mechanism by any network device. 356 For the purpose of describing the operation of this service, two 357 devices are considered: the requesting node and the target. In gen- 358 eral, the requesting node wants to verify the reachability of the 359 target. The operation is as follows: 361 o The requesting node sends an FRD message to the target. 363 o The target sends an FRR message that includes a logical NOT of 364 the information in the Data field of the FRD message. 366 The FRD message MAY be sent directly to the target or to a well-known 367 multicast address specific to the underlying media. If a multicast 368 destination is used, then several targets MAY reply. The FRR message 369 MUST always be sent to the requesting node. 371 4.3. An Example of MARP Operation 373 This section presents an example of MARP being used to provide the 374 reachability notification service. 376 Given the following network: 378 R1----(port1)S1(port2)----(port3)S2(port4)----R2 380 In the figure, R1 and R2 are MARP clients, while S1 and S2 are MARP 381 servers. 383 1 R1 sends an UPDATE message that includes R2's address in it. 385 2 S1 determines that R2's address is reachable via port2, and 386 would thus mark port2 with enough information to note that the 387 failure of this port would be an "interesting" event. The 388 UPDATE message is also forwarded by S1 out all ports on the same 389 broadcast domain, including port2. 391 3 S2 receives the UPDATE message on port3, and finds R2's address 392 available through port4, so it marks port4 as "interesting". 393 The UPDATE message is also forwarded by S2 out all ports on the 394 same broadcast domain, including port4. 396 4 Two independent failure scenarios may occur. 398 4a The link between S1 and S2 fails. S1 will now send a 399 notification message (NOTIFY_HARD or NOTIFY_SOFT according 400 to the local configuration), with R2's address in it, out 401 all ports on the same broadcast domain as port2, including 402 port1. 404 4b The link between S2 and R2 fails. S2 will now send a 405 notification message (NOTIFY_HARD or NOTIFY_SOFT according 406 to the local configuration), with R2's address in it, out 407 all ports on the same broadcast domain as port4, including 408 port3. On receiving this notification message, S1 must for- 409 ward it out all links on the same broadcast domain (except 410 the one ot was received on), including port1. 412 5 R1 receives the notification message indicating that R2's 413 address is no longer reachable. 415 5a If a NOTIFY_SOFT message was received, then R1 may send an 416 FRD message to verify R2's reachability. 418 5b R1 may take a locally defined action. 420 5. Security Considerations 422 This document presents a new protocol which provides a mechanism for 423 a device to notify another device that a particular destination is no 424 longer reachable within a given broadcast domain. While the threat 425 zone is limited to only the local broadcast domain, it is recommended 426 that authentication be used to minimize the threat of false (or 427 spoofed) notifications of lost connectivity. 429 6. IANA Considerations 431 The section "MARP Packet Format" defines the fields that make up a 432 MARP packet and it defines meaning to some of the values in them. 433 IANA is expected to maintain the registry for these values as fol- 434 lows. 436 L2 Sub-Type Field: 438 o This field is to be used by the underlying layer 2 media. If 439 not specifically needed by the underlying transport, then it 440 MUST be treated as a Reserved field (described below). 442 Reserved Fields: These fields, or parts of them, MUST be assigned 443 using the "IETF Consensus" policy defined in RFC2434 [RFC2434]. 445 Version Number Field: 447 o Version number 0 is reserved. 449 o Version number 1 is assigned to the current version specified in 450 this document. 452 o Version numbers 2 through 127 MUST be assigned using the "IETF 453 Consensus" policy defined in RFC2434 [RFC2434]. 455 o Version numbers 128 through 191 SHOULD be assigned using the 456 "Specification Required" policy defined in RFC2434 [RFC2434]. 458 o Version numbers 192 through 255 are for "Private Use" as defined 459 in RFC2434 [RFC2434]. 461 TLV Type Field: 463 o Type code 0 is reserved. 465 o Type codes 1, 2 and 3 are assigned in this document. 467 o Type codes 4 through 127 MUST be assigned using the "IETF Con- 468 sensus" policy defined in RFC2434 [RFC2434]. 470 o Type codes 128 through 191 SHOULD be assigned using the "Specif- 471 ication Required" policy defined in RFC2434 [RFC2434]. 473 o Type codes 192 through 255 are for "Private Use" as defined in 474 RFC2434 [RFC2434]. 476 Authentication Type Field: 478 o Types 0 through 2 are explicitly defined in this document. 480 o Authentication Type values 3 thru 63 MUST be assigned using the 481 "IETF Consensus" policy defined in RFC2434 [RFC2434]. 483 o Authentication Type values 64 thru 127 SHOULD be assigned using 484 the "Specification Required" policy defined in RFC2434 485 [RFC2434]. 487 o Authentication Type values 128 thru 255 are for "Private Use" as 488 defined in RFC2434 [RFC2434]. 490 Opcode Field (Reachability Notification TLV): 492 o Bit 15 (high order bit) is reserved to indicate if the remaining 493 bits are vendor specific or not. 495 o Bits 0 and 1 (two low order bits) are reserved to indicate the 496 message type. 498 o Bits 2 through 4 (and its combinations with bits 0 and 1) are to 499 be used for additional message types and SHOULD be assigned 500 using the "IETF Consensus" policy defined in RFC2434 [RFC2434]. 502 o Bits 5 through 9 MUST be assigned using the "IETF Consensus" 503 policy defined in RFC243 [RFC2434]. 505 o Bits 10 through 14 SHOULD be assigned using the "Specification 506 Required" policy defined in RFC2434 [RFC2434]. 508 Opcode Field (Fast Reachability Verification TLV) 510 o Bit 7 (high order bit) is reserved to indicate if the remaining 511 bits are vendor specific or not. 513 o Bit 0 (low order bit) is reserved to indicate the message type. 515 o Bits 1 through 4 MUST be assigned using the "IETF Consensus" 516 policy defined in RFC243 [RFC2434]. 518 o Bits 5 through 6 SHOULD be assigned using the "Specification 519 Required" policy defined in RFC2434 [RFC2434]. 521 7. Intellectual Property Considerations 523 The IETF has been notified of intellectual property rights claimed in 524 regard to some or all of the specification contained in this docu- 525 ment. For more information consult the online list of claimed rights. 527 8. Acknowledgements 529 We want to acknowledge David Oran, who had the original idea from 530 which MARP grew. We would like to thank all the people (too many to 531 list individually) who have shown interest in MARP for their valuable 532 input. 534 9. References 536 [RFC2119] 537 Bradner, S., "Key words for use in RFCs to Indicate Requirement 538 Levels," RFC 2119, March 1997. 540 [ISIS_SHORT] 541 Parker, J., McPherson, D., and Alaettinoglu, Cengiz, "Short Adja- 542 cency Hold Times in IS-IS", Work In Progress (draft-parker-short- 543 isis-hold-times-01.txt), July 2001. 545 [LSP_PING] 546 Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow, G., Wadhwa, 547 S., and Bonica, R., "Detecting Data Plane Liveliness in MPLS", 548 Work In Progress (draft-ietf-mpls-lsp-ping-00.txt), March 2002. 550 [FLIP] 551 Sandick, H., Squire, M., Cain, B., Duncan, I., Haberman, B., "Fast 552 LIveness Protocol (FLIP)", Work In Progress (draft-sandiick-flip- 553 00.txt), February 2000. 555 [PLP] 556 Kompella, K., "Protocol Liveness Protocol", Work In Progress 557 (draft-kompella-rag-plp-00.txt), October 2002. 559 [MD5] 560 Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, April 561 1992. 563 [RFC2434] 564 Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Con- 565 siderations Section in RFCs", RFC 2434, BCP 26, October, 1998. 567 10. Authors' Addresses 569 Alvaro Retana 570 Cisco Systems, Inc. 571 7025 Kit Creek Rd. 572 Research Triangle Park, NC 27709 573 EMail: aretana@cisco.com 575 Russ White 576 Cisco Systems, Inc. 577 7025 Kit Creek Rd. 578 Research Triangle Park, NC 27709 579 EMail: riw@cisco.com