Network Working Group Alvaro Retana Internet Draft Russ White Expiration Date: May 2003 Cisco Systems, Inc. File Name: draft-retana-marp-01.txt November 2002 MultiAccess Reachability Protocol (MARP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http//www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http//www.ietf.org/shadow.html. Abstract This document defines a protocol to quickly determine the existence or aliveness of devices attached to a shared media (broadcast) subnet. While the examples used are narrowly defined for simplicity, the protocol could be applied to other situations as well. 1. Motivation There is a great deal of interest in discovering when a device drops off of a broadcast (shared) media link for various purposes, not limited to: o Loss of routing protocol neighbors. Routing protocols would like to discover the loss of a neighbor as quickly as possible so they can reconverge around the topology change, dropping as lit- tle traffic as possible. o Loss of a server. If multiple servers, offering the same Retana, White [Page 1] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) November 2002 service, exist on a segment, a device which is load balancing traffic between those servers would like to know as soon as one of them fails. Towards this end, several solutions ([ISIS_SHORT], [LSP_PING] and [FLIP], for example) have been designed, most (or all) of which rely on some sort of "fast aliveness" or "fast hello" protocol to quickly determine the failure of a node on a shared media segment. There is some question about the scalability of such protocols, since there could be hundreds of devices on a single high speed broadcast net- work, and a single device could be connected to hundreds of broadcast networks. Most devices in today's networks are not connected to a true broacast segment (such as a 10base5 coax cable), but are instead connected to a layer 2 switch (using point-to-point connections) that can deter- mine if a device is still alive based on the carrier detect circuitry at the physical or data link layers. It should be possible to somehow harness this immediate and constant status information to inform other network devices about state changes for a particular device. This document defines the MultiAccess Reachability Protocol (MARP), which allows for the fast notification of loss of connectivity to devices attached to a shared media (broadcast) subnet. 2. MARP Packet Format MARP runs directly over layer 2; all packets are sent to a well-known (TBD) multicast address specific to the underlying layer 2 media. The data portion of the packet has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+ | Version | Length | Reserved | +---------------+---------------+-------------------------------+ | Opcode | Hold | +---------------+---------------+---------------+---------------+ | Holddown | Auth Type | Reserved | +-----------------------------------------------+---------------+ | Authentication String... | +---------------------------------------------------------------+ | | | Layer 2 Address | | | | | +---------------------------------------------------------------+ Retana, White [Page 2] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) November 2002 o Version (1 octet): Protocol version number; current version is 1. o Length (2 octets): The total length of the packet in octets. o Opcode (2 octets): A bit field containing information about how the packet should be handled (described below). o Hold (2 octets): The number of minutes the receiving device should track the list of layer 2 addresses included in the packet; note the hold time of any given entry need not match the hold time of any other entry on the network o Holddown (1 octet): The time in seconds a port which loses connectivity to the addresses listed in the packet should be held in the down state. o Authentication Type (1 octet): an unsigned integer indicating the type of authentication present (described below). o Authentication String (variable length): contains the authen- tication information. o Layer 2 Address (16 octets - more than one field may be present in a packet): each field contains one layer 2 address. The format of the address depends on the underlying media. Layer 2 addresses which are less than 16 octets in length MUST be padded with 0's on the left (msd padding). o Reserved: These fields are reserved for future use. The SHOULD be sent as 0 and ignored by the receiver. The Opcode field is used to determine how a MARP packet should be processed when it is received. o If the high order bit of this field is set, then the remain- ing 15 bits are vendor implementation specific. If clear, then the remaining 15 bits are implemented according to this document. o The two low order bits indicate the MARP packet type: 00 UPDATE: MARP servers should provide notification when reachability to the layer 2 devices listed fails. MARP clients should ignore this packet. 01 NOTIFY_HARD: Reachability to the layer 2 devices listed has failed. Only a server should send this message Retana, White [Page 3] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) November 2002 type. 10 NOTIFY_SOFT: Reachability to the layer 2 devices listed may have failed. Only a server should send this message type. 11 REMOVE: MARP servers should remove the layer 2 address listed in the packet from their local MARP table. The Authentication Type field serves to indicate what type of is present in the MARP packet, as well as how long the authentication information is. 0 No authentication included (authentication string not present). 1 Plain text authentication included (authentication string is 16 octets). 2 MD5 [MD5] authentication included (authentication string is 16 octets). 3. MARP Operation Several factors were taken into consideration when designing MARP, including: o The monitored device or the monitoring device should be able to request notification of state changes. o Devices monitoring the state of other devices should be required to maintain as little state as possible. o The protocol used to signal monitoring requests and state changes should be as simple as possible to reduce any processing overhead. Three sections follow: one discusses the operation of MARP within a MARP client, while the other discusses the processing MARP packets by devices providing MARP notifications (a MARP server). Note that a single device may be a MARP server and a MARP client at the same time. Retana, White [Page 4] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) November 2002 3.1. MARP Client Operation Layer 3 devices connected to a common multiaccess layer 2 network may become MARP clients. In general, a MARP client requires that a peer (such as a routing protocol neighbor, for example) be tracked and that a notification be received if the peer is no longer reachable. Once the client has determined which peer relationships to monitor, it can: o Discover the layer 2 addresses of each adjacent peers using layer 2 to layer 3 mapping methods. o Using MARP, periodically declare their peers' layer 2 addresses as interesting to other devices connected to the network. A client may also periodically advertise its own address. The list of layer 2 addresses to be tracked must be periodically advertised before the specified Hold Time expires. A client that receives a NOTIFY_HARD or NOTIFY_SOFT message MAY use this information to reset known adjacencies, check adjacency status, or take other action as deemed appropriate locally. If a REMOVE packet is received, the client SHOULD examine the list of layer 2 addreses. If one of the addresses is still of interest to the local device, then a new UPDATE packet MUST be advertised. 3.2. MARP Server Operation In general, a MARP server is a layer 2 device that is capable of tracking the reachability of other devices on the local multiaccess segment. If a received packet is an UPDATE, for each layer 2 address listed in it, the MARP server MUST: o Examine its local connectivity tables to determine reachability to it. o If the address is found to not be reachable, then it should be silently ignored. o If the address is found to be reachable, the Hold Time MUST be set to the maximum of the current value or the time specified in the packet. The Holdown Time MUST be set to the maximum of the current value or the time specified in the packet. Retana, White [Page 5] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) November 2002 A MARP server SHOULD stop tracking any layer 2 addresses listed in a REMOVE packet. It is recommended that the server stop tracking the address only once a locally configurable grace period has expired to allow other clients to send an UPDATE if continued monitoring is required. A MARP server MUST stop tracking any layer 2 addresses listed in a NOTIFY_HARD packet. MARP servers SHOULD ignore any NOTIFY_SOFT packets. In conjunction with processing the packets as described, the server MUST also forward the packets according to the local multicast forwarding rules. If a MARP server detects loss of connectivity to a layer 2 address it is tracking (the Hold Time has not expired), it MUST send a notifica- tion (NOTIFY_HARD or NOTIFY_SOFT according to the local configura- tion). If the loss of connectivity was due to a port failure (physi- cal or logical), then the corresponding port SHOULD be maintained in the down state for the length of the corresponding Holdown Time. 3.3. An Example of MARP Operation Given the following network: R1----(port1)S1(port2)----(port1)S2(port2)----R2 In the figure, R1 and R2 are MARP clients (L3 routers, in this exam- ple), while S1 and S2 are MARP servers (L2 switches in this case). Suppose R1 sends out a MARP update stating it wants to watch R2's MAC address. S1 would determine that R2's MAC address is reachable via port2, and would thus mark port2 with enough information to note that the failure of this port would be an interesting event. Since the MARP update was received on port1, and port2 is a member of the same L2 network (VLAN or broadcast domain), S1 would forward this MARP update through port2. S2 will receive the MARP update on its port1, and will search its local tables to determine on which port the layer 2 address indicated in the packet is reachable. It finds this address available through port2, so it marks port2 as "interesting" as well. If the link between S1 and S2 fails, S1 will now send a MARP notifi- cation on all ports in the same broadcast domain as the interesting layer 2 address losing connectivity (R2's MAC). This notification may be a hard notification, or a soft notification, depending on the local configuration of S1. Some ways S2 may determine which type of notification to transmit include: Retana, White [Page 6] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) November 2002 o It has determined that port2 is connected to another switch, possibly though momintoring BPDU or other traffic, for example. o A system administrator has manually configured the switch to transmit soft notifications for events on this port. The notification would be transmitted through port1, and received by R1, which could then make some decision on how to treat this informa- tion. If the link between S2 and R2 fails, S2 could send either a hard or soft MARP notification on all ports within the same broadcast domain. This would cause S2 to send a notification through port1 which S1 would receive. On receiving this MARP notification, S2 may remove the layer 2 address (R2's MAC) from its local tables. S1 MUST forward this MARP notification out all links on the same broadcast domain that the packet was not received on before processing it locally. Thus, the notification generated by S2 would be forwarded to R1, which could use this information to take whatever action is deemed necessary. 3.4. Extending MARP This document has been written in terms of layer 2 and layer 3 func- tionality, and illustrated in a simple ethernet network (above). How- ever, the functionality is easily extended to allow MARP to be used in other environmentes that meet the client/server definition para- digm. 4. IANA Considerations The section "MARP Packet Format" defines the field that make up a MARP packet and it defines meaning to some of the values in it. IANA is expected to maintain the registry for these values as follows. Version Number Field: o Version number 0 is reserved. o Version number 1 is assigned to the current version specified in this document. o Version numbers 2 through 127 MUST be assigned using the "IETF Consensus" policy defined in RFC2434 [RFC2434]. Retana, White [Page 7] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) November 2002 o Version numbers 128 through 191 SHOULD be assigned using the "Specification Required" policy defined in RFC2434 [RFC2434]. o Version numbers 192 through 255 are for "Private Use" as defined in RFC2434 [RFC2434]. Opcode Field: o Bit 15 (high order bit) is reserved to indicate if the remaining bits are vendor specific or not. o Bits 0 and 1 (two low order bits) are reserved to indicate the MARP packet type. o Bits 2 through 4 (and its combinations with bits 0 and 1) are to be used for additional MAPR packet types and SHOULD be assigned using the "IETF Consensus" policy defined in RFC2434 [RFC2434]. o Bits 5 through 9 MUST be assigned using the "IETF Consensus" policy defined in RFC243 [RFC2434]. o Bits 10 through 14 SHOULD be assigned using the "Specification Required" policy defined in RFC2434 [RFC2434]. Reserved Field: This field, or parts of it, MUST be assigned using the "IETF Consensus" policy defined in RFC2434 [RFC2434]. Authentication Type Field: o Types 0 through 2 are explicitly defined in this document. o Authentication Type values 3 thru 63 MUST be assigned using the "IETF Consensus" policy defined in RFC2434 [RFC2434]. o Authentication Type values 64 thru 127 SHOULD be assigned using the "Specification Required" policy defined in RFC2434 [RFC2434]. o Authentication Type values 128 thru 255 are for "Private Use" as defined in RFC2434 [RFC2434]. Retana, White [Page 8] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) November 2002 5. Intellectual Property Considerations Cisco Systems may seek patent or other intellectual property protec- tion for some or all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them on reasonable and non- discriminatory terms. 6. Security Considerations This document defines a new protocol that operates directly over a layer 2 transport. The protocol is used to determine the existence (or not) of other devices on a multiaccess network. While the threat zone is limited to only the local layer 2 segment, it is recommended that authentication be used to minimize the threat of false (or spoofed) notifications of lost connectivity. 7. Acknowledgements We want to acknowledge David Oran, who had the original idea from which MARP grew. We would like to thank all the people (too many to list individually) for their valuable input. 8. References [ISIS_SHORT] Parker, J., McPherson, D., and Alaettinoglu, Cengiz, "Short Adja- cency Hold Times in IS-IS", Work In Progress (draft-parker-short- isis-hold-times-01.txt), July 2001. [LSP_PING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow, G., Wadhwa, S., and Bonica, R., "Detecting Data Plane Liveliness in MPLS", Work In Progress (draft-ietf-mpls-lsp-ping-00.txt), March 2002. [FLIP] Sandick, H., Squire, M., Cain, B., Duncan, I., Haberman, B., "Fast LIveness Protocol (FLIP)", Work In Progress (draft-sandiick-flip- 00.txt), February 2000. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, April 1992. Retana, White [Page 9] INTERNET DRAFT MultiAccess Reachability Protocol (MARP) November 2002 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Con- siderations Section in RFCs", RFC 2434, BCP 26, October, 1998. 9. Authors' Addresses Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 EMail: aretana@cisco.com Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 EMail: riw@cisco.com Retana, White [Page 10]