idnits 2.17.1 draft-sandiick-flip-00.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1142 lines 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 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** 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 251: '...onds. This value MUST be larger than t...' RFC 2119 keyword, line 274: '...Note: A device MAY use the HelloInterv...' RFC 2119 keyword, line 275: '...nterfaces, or it MAY use different one...' RFC 2119 keyword, line 276: '...These parameters MUST be configurable ...' RFC 2119 keyword, line 277: '... timer intervals SHOULD be configurabl...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 395 has weird spacing: '... a node shoul...' == Line 611 has weird spacing: '...as been estab...' -- 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 (February 2000) is 8836 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) == Missing Reference: 'FLIPAdvertisementDeadInterval' is mentioned on line 229, but not defined == Missing Reference: 'RFC2476' is mentioned on line 542, but not defined ** Obsolete undefined reference: RFC 2476 (Obsoleted by RFC 4409) == Missing Reference: 'FLIPAdvertismentInterval' is mentioned on line 674, but not defined == Missing Reference: 'FLIPNewAdvertisement' is mentioned on line 680, but not defined == Missing Reference: 'FLIPNewAdvertisment' is mentioned on line 681, but not defined == Unused Reference: 'RFC1256' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'IANAAFN' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 704, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAAFN' Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XXXX Working Group H.Sandick, M.Squire, B.Cain 3 Internet Draft I. Duncan, B.Haberman 5 draft-sandiick-flip-00.txt Nortel Networks 7 February 2000 8 Expires XXX 2000 10 Fast LIveness Protocol (FLIP) 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other groups 19 may also distribute working documents as Internet-Drafts. Internet- 20 Drafts are draft documents valid for a maximum of six months and may be 21 updated, replaced, or obsoleted by other documents at any time. It is 22 inappropriate to use Internet- Drafts as reference material or to cite 23 them other than as "work in progress." The list of current Internet- 24 Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 Networks and network applications must be robust and reliable. For 32 many applications and services, such as packetized voice, correcting a 33 failure must be almost instantaneous. The first step in correcting a 34 failure is, of course, detecting that it occurred. IP routing 35 protocols and signaling protocols as well as many application layer 36 protocols incorporate their own keepalive mechanisms to detect 37 failures. Typically, these protocols detect failures on the order of 38 seconds or tens of seconds. While there are some physical and link 39 layer technologies that inherently supply link outage detection, not 40 all link layers do this. In order to provide for fast failure 41 detection over any type of lower layer, an IP layer fast keepalive 42 protocol can be used. This draft describes such a protocol for quickly 43 detecting when a network layer interface of a peer has failed. 45 Table Of Contents 47 1 Terminology ........................................................2 48 2 Introduction .......................................................3 49 3 Protocol Overview ..................................................4 50 4 Neighbor Discovery and Negotiation .................................5 51 4.1 Neighbor Discovery ..............................................5 53 Sandick, Squire, Cain, Duncan, Haberman 54 1 55 4.2 Parameters ......................................................5 56 4.3 Negotiation Rules ...............................................6 57 4.4 FLIP Solicitation Protocol Description ..........................7 58 4.5 FLIP Advertisement Protocol Description .........................7 59 4.6 Finite State Machine (FSM) for Neighbor Adjacency ...............8 60 5 FLIP Hello Protocol ...............................................10 61 5.1 Protocol Description ...........................................10 62 5.2 Hello Message Contents .........................................11 63 5.3 Finite state machine for Hello Message Exchange ................11 64 6 Hello Exchange over NBMA links ....................................13 65 7 Default Values ....................................................13 66 7.1 All-FLIP-Peers .................................................13 67 7.2 HelloInterval ..................................................13 68 7.3 PeerDeadInterval ...............................................13 69 7.4 FLIPAdvertisementInterval ......................................14 70 7.5 FLIPNewAdvertisement ...........................................14 71 7.6 FLIPAdvertisementDeadInterval ..................................14 72 7.7 FLIPNewAdvertisementInterval ...................................14 73 8 Security Considerations ...........................................14 74 9 Intellectual Property Considerations ..............................14 75 10 References ......................................................15 76 A. Setting the HelloInterval .......................................15 77 B. Formats .........................................................16 78 B.1 FLIP Advertisement Message .....................................16 79 B.2 FLIP Solicitation Message ......................................18 80 B.3 FFLIP Hello Message ............................................19 82 1 Terminology 84 Adjacency see Neighbor Adjacency 86 Adjacency failure Communication with a neighbor interfaces 87 is no longer possible 89 Device The logical entity that owns or controls 90 one or more logical IP interfaces. A 91 device can be a host or a router. 93 GroupID Identifies a particular set of peers, 94 e.g. routers. 96 Neighbor A directly connected peer on a shared 97 subnet. 99 Sandick, Squire, Cain, Duncan, Haberman 2 100 Interface The physical or logical interface(S) used 101 to communicate on a particular IP subnet. 102 The interface is defined by the IP 103 address for the interface on that subnet. 104 Unnumbered interfaces have the IP address 105 "0.0.0.0" 107 Neighbor Adjacency Established communication with peer over 108 on a shared IP subnet defined by the 109 respective IP addresses of the local and 110 peer's interfaces. In the case of 111 unnumbered interface, the interface is 112 defined by the interface and has the IP 113 address "0.0.0.0". 115 Neighbor Interface The physical or logical interface(S) that 116 a peer uses to communicate on a 117 particular IP subnet. 119 Peer A target device whose IP connectivity is 120 monitored by another device on the same 121 IP link layer or subnet. 123 Peer failure A Peer becomes unreachable over all of 124 its interfaces 126 PeerID An unique identifier for a Peer 128 2 Introduction 130 Networks and network applications must be robust and reliable. For 131 many applications and services, such as packetized voice, correcting a 132 failure must be almost instantaneous. The first step in correcting a 133 failure is, of course, detecting that it occurred. IP routing 134 protocols and signaling protocols as well as many application layer 135 protocols incorporate their own keepalive mechanisms to detect 136 failures. Typically, these protocols detect failures on the order of 137 seconds or tens of seconds. While, there are some physical and link 138 layer technologies that inherently supply link outage detection, not 139 all link layers do this. In order to provide for fast failure 140 detection over any type of lower layer, an IP layer fast keepalive 141 protocol can be used. This draft describes such a protocol for quickly 142 detecting when a network layer interface of a peer has failed. 144 This document describes a general-purpose peer-to-peer neighbor 145 adjacency protocol, which is designed to detect failures at the IP 146 protocol layer over a variety of media. This protocol uses periodic 147 hello messages between peers on the same IP subnet to determine "link 148 aliveness." We feel that a fast IP layer keepalive is necessary to 149 assist in detecting failures over a variety of lower layer protocols 151 Sandick, Squire, Cain, Duncan, Haberman 3 152 that may or may not provide this capability themselves. A generic fast 153 hello protocol provides mainly two benefits. The first is a generic 154 protocol for neighbor discovery. The second is support for fast link 155 failures over any media type. 157 We present three examples to illustrate the usefulness of our protocol. 158 Currently, there are many "IP only" Internet service providers. These 159 providers must rely on failure notifications from a layer-2 network 160 operated by another carrier. In some instances the IP only carrier may 161 wish to have its own methods and parameters for determining failures. 162 IP routing protocols (e.g. OSPF or IS-IS Hello) for example may be 163 used, but they typically have lower frequency thresholds at which they 164 can operate. Another scenario that illustrates the usefulness of a 165 generic approach is IP over WDM. In this case, the IP layer may handle 166 all of the signaling and control aspects of the network including 167 aspects of failure detection. A third scenario might involve a 168 synchronization protocol between web servers on the same subnet. 170 3 Protocol Overview 172 The FFLIP protocol is designed to be generic, extensible and by 173 definition, work over any types of media including NBMA and broadcast 174 subnets. In order to accommodate these somewhat conflicting 175 requirements, we divide the protocol into two "sub-protocols". 177 The first sub-protocol, the FLIP Advertisement protocol, is used for 178 neighbor discovery and parameter negotiation. This protocol makes use 179 of a new type of ICMP message. These advertisements are multicast at a 180 low frequency and are used to discover FLIP aware neighbors on a local 181 subnet. Once neighbors have been discovered, adjacencies are formed. 182 Advertisements contain a list of neighbors that have been heard from; a 183 device considers an adjacency to be formed when the device finds its 184 address in a neighbor's advertisement. In the case of unnumbered 185 interfaces the list can only contain one address, "0.0.0.0". Once an 186 adjacency is established, devices use a simple negotiation method to 187 decide on operating parameters. This negotiation is simply an 188 agreement on the lowest common denominator of each parameter between 189 the parameters sent in their advertisements. 191 For each adjacency established with the advertisement protocol, a 192 second sub-protocol, the FLIP Hello protocol is used as a fast 193 keepalive between two peers. This protocol is the actual protocol used 194 for fast link failure detection. It defines a fixed format hello 195 message that is exchanged (unicast) between every adjacency. The FLIP 196 hello is used to determine the status of a link and therefore operates 197 at very high frequencies; it may be desirable to implement this 198 protocol in a hardware implementation. For example, a device may 199 include processing for FLIP Hellos in a line card. 201 In order to provide fast detection for other protocols operating in a 202 device (e.g. routing protocols), an implementation should treat FFLIP 204 Sandick, Squire, Cain, Duncan, Haberman 4 205 detected failures as neighbor adjacency failures. FFLIP is independent 206 of other individual hello protocols (e.g. OSPF or IS-IS Hello), and can 207 be used to signal link failures in a device. 209 4 Neighbor Discovery and Negotiation 211 4.1 Neighbor Discovery 213 In order to discover other FFLIP capable peers on a subnet, the FLIP 214 Advertisement is used. The FFLIP Advertisement is similar to the ICMP 215 Router Advertisement protocol. We define a new message type: FFLIP 216 Advertisement, which is used by peers to advertise their support of the 217 protocol and to advertise their configured parameters. 219 In order to discover all neighbors on a subnet, FFLIP Advertisements 220 are multicast to the All-FFLIP-Peers address and contain a PeerID. 221 Devices send these messages periodically over IP interfaces that have 222 the FLIP protocol enabled. A neighbor adjacency, i.e. bi-directional 223 connectivity, is established by listing neighbor interfaces that have 224 been heard in an advertisement. Once a FLIP Advertisement is heard 225 from a neighbor, the neighbor interface is listed in a device's own 226 FLIP Advertisement for that interface. In the case of unnumbered 227 interfaces the address "0.0.0.0" is added to the list. If an 228 advertisement containing the receiving devices interface has not been 229 received by a neighbor in [FLIPAdvertisementDeadInterval] seconds, that 230 neighbor is declared down. 232 All FLIP messages use ICMP Type field (X). The FLIP Advertisement is 233 the only currently defined message with the ICMP Code field set to 234 zero. 236 4.2 Parameters 238 FFLIP Advertisements are also used to advertise the parameters 239 necessary for the operation of the protocol. The FLIP Advertisement 240 contains several parameters: the HelloInterval, the PeerDeadInterval, 241 the PeerID of the transmitting device, The GroupID and the list of 242 neighbor interfaces that the transmitting device has heard from. 244 The HelloInterval and the PeerDeadInterval are used to set the 245 operational parameters of the FLIP Hello message. The HelloInterval 246 indicates how often FFLIP Hello messages will be sent and is measured 247 in milliseconds (ms). For example, if the value is 3 then the 248 advertising device would send the Hello message at least every 3 ms. 249 The PeerDeadInterval indicated how long a device should wait (from the 250 last Hello) before declaring a neighbor failure. PeerDeadInterval is 251 specified in milliseconds. This value MUST be larger than the 252 HelloInterval and should be at least 3 times the value of the 253 HelloInterval. (NOTE: Should there be a minimum multiple, say 3 time) 255 Sandick, Squire, Cain, Duncan, Haberman 5 256 The PeerID is the globally unique identifier assigned to that device. 257 A device must use the same PeerID in all FLIP Advertisements. The 258 PeerID allows receiving devices to correlate multiple interfaces with 259 the peer that owns them. 261 The GroupID identifies the group of peers that this advertisement is 262 targeted for. 264 The list of neighbor interfaces is used to establish neighbor 265 adjacencies. The list contains the neighbor interfaces that a device 266 has received advertisements from over a particular IP link layer. In 267 the case of unnumbered interfaces the list can only contain one 268 address, "0.0.0.0". If a device receives an advertisement containing 269 its interface, the device assumes that connectivity to that neighbor 270 has been established. In the case of an unnumbered interface the IP 271 address "0.0.0.0" indicates the device's advertisement has been 272 received. 274 Note: A device MAY use the HelloInterval and PeerDeadInterval for all 275 of its interfaces, or it MAY use different ones over different 276 interfaces. These parameters MUST be configurable for each device, and 277 the timer intervals SHOULD be configurable independently on each 278 interface. The means by which a device configures the values for its 279 initial operation are outside this specification. 281 4.3 Negotiation Rules 283 It is possible that two neighbors will be configured with different 284 values for their operating parameters. Values must be agreed upon 285 before the hello messaging can begin. FLIP uses a simple negotiation 286 scheme that is simply lowest common denominator. FLIP negotiation is 287 on a per adjacency basis, NOT a subnet basis. The rules for 288 negotiation are: 290 (a) If the HelloInterval values are different, then the parameters 291 (HelloInterval and PeerDeadInterval) from the neighbor 292 associated with the larger HelloInterval are selected to be 293 used by both neighbors. 294 (b) Otherwise, if the PeerDeadInterval values are different, then 295 the parameters associated with the neighbor advertising the 296 larger PeerDeadInterval are selected to be used by both 297 neighbors. 299 The larger values are selected (instead of the smaller values) to 300 accommodate environments where one of the devices cannot operate at the 301 same parameters as the other device. In this case, the faster device 302 must in a sense `slow down' for the slower device. 304 Sandick, Squire, Cain, Duncan, Haberman 6 305 After a negotiation is applied, a device does not change the parameters 306 that are sent in its advertisement. The parameters sent in an 307 advertisement are a device's configured parameters and may or may not 308 be the actual parameters used with a given adjacency. The actual 309 parameters used with an adjacency are those which are computed from the 310 negotiation rules. 312 Each device SHOULD apply a small jitter factor to the HelloInterval, 313 rendering the actual parameter to between 75% and 100% of the selected 314 value. The same jitter should be applied to the PeerDeadInterval 316 4.4 FLIP Solicitation Protocol Description 318 The FLIP protocol is enabled per IP interface; FLIP protocol state is 319 per interface, per neighbor. When a FLIP enabled interface first 320 become enabled it sends a FLIP Solicitation message to the 321 AllFLIPDevices address. The address is sent FLIPSolicitationReSend 322 times FLIPSolicitationInterval apart. When a device receives a FLIP 323 Solicitation message it unicasts a FLIP Advertisement to the source 324 address of the Solicitation message. The Advertisement contains the 325 source address of the Solicitation in it list of neighbor interfaces. 326 The FLIP Solicitation message uses the same format as the FLIP 327 Advertisement but some parameters are set differently. 329 A valid FLIP Advertisement is one which: 330 1. 331 IP header and ICMP checksums pass 332 2. 333 ICMP Type = X 334 3. 335 ICMP Code = 1 336 4. 337 HelloInterval > 0 338 5. 339 PeerDeadInterval > HelloInterval 340 6. 341 Valid Address Family 342 7. 343 Non-zero PeerID 344 8. 345 Neighbor Interfaces = 0 347 4.5 FLIP Advertisement Protocol Description 349 After the FLIP Solicitation message is sent FLIP Advertisements are 350 sent every FFLIPAdvertisementSeconds with a small amount of jitter. 351 When a device receives a FLIP Advertisement from a neighbor, it lists 352 the neighbor interface in its own FLIP advertisements for that 353 interface. If a device receives an advertisement containing its own 354 interface in one of the neighbor fields and it has listed that neighbor 355 in its own advertisement, a FLIP adjacency is established. If an 356 advertisement containing the receiving device interface has not been 357 received from a neighbor in FLIPAdvertisementDeadInterval seconds, then 358 that neighbor is removed from subsequent advertisements (for that 359 interface) and the adjacency is considered down. 361 Once a FLIP adjacency is established, a device applies the negotiation 362 rules in section 4.3 on a per neighbor basis. They immediately begin 364 Sandick, Squire, Cain, Duncan, Haberman 7 365 the FLIP Hello protocol described in section 5. If there is an 366 adjacency failure, then the FLIP Hello protocol is ceased for that 367 neighbor. 369 When a FLIP Advertisement is received, the source IP address of the 370 advertisement should be stored with all neighbor state. This address 371 is used in the FLIP Hello protocol (see section 5). In the case of 372 unnumbered interface the source address is "0.0.0.0". 374 A valid FLIP Advertisement is one which: 376 1. 377 IP header and ICMP checksums pass 378 2. 379 ICMP Type = X 380 3. 381 ICMP Code = 0 382 4. 383 HelloInterval > 0 384 5. 385 PeerDeadInterval > HelloInterval 386 6. 387 Valid Address Family 388 7. 389 Non-zero PeerID 391 If a device chooses to modify its FLIP parameters for an interface, it 392 MUST multicast a FLIP Advertisement with the new parameters at least 393 FLIPNewAdvertisement times within FLIPNewAdvertisementInterval. When a 394 FLIP Advertisement is received from a neighbor, which would cause a 395 renegotiation, a node should immediately unicast an advertisement of 396 its own on the interface to that neighbor. If a renegotiation occurs, 397 the new parameters should immediately be applied to the FLIP Hello 398 protocol. 400 If a device decides that a particular neighbor has not adjusted its 401 operating parameters sufficiently, then the device MAY unicast an FLIP 402 Advertisement to that neighbor. If the parameters are sufficiently 403 different, the neighbor's hello protocol will fail and it will have to 404 re-discover this device and its new operating parameters. 406 4.6 Finite State Machine (FSM) for Neighbor Adjacency 408 This FSM formally details how neighbor adjacency state is created, 409 maintained and deleted. We adopt the notation of X(y), where X is the 410 new state transitioned to after action y has been applied. A "-" means 411 that no state transition or action is performed. This FSM is the state 412 machine for the FLIP adjacency protocol. Behavior global to the 413 interface such as the periodic sending of FLIP Advertisements are not 414 part of this FSM. 416 Sandick, Squire, Cain, Duncan, Haberman 8 417 State 418 | | | | 419 Input | 0 | 1 | 2 | 420 ------+---------+---------+---------+ 421 | | | | 422 A | -(n) | 0(n) | 0(d) | 423 ------+---------+---------+---------+ 424 | | | | 425 | | | | 426 B | 1(n) | -(n) | 1(d) | 427 ------+---------+---------+---------+ 428 | | | | 429 C | 2(b) | 2(b) | -(a) | 430 ------+---------+---------+---------+ 431 | | | | 432 D | NA | NA | -(c) | 433 ------+---------+---------+---------+ 434 | | | | 435 E | NA | NA | 0(e) | 436 ------+---------+---------+---------+ 438 States 439 ------ 441 Init (0): This is the initial state at which the protocol begins. In 442 this state, FLIP Advertisements are sent; No advertisements have been 443 received for the neighbor. 445 Half (1): This state is transitioned to after an advertisement is 446 received from the neighbor. But bi-directional connectivity has not yet 447 been established, i.e. A FLIP Advertisement containing the receiving 448 devices interface has not been received. 450 Full (2): When a receiving device sees its interface in its neighbor's 451 advertisement then bi-directional connectivity has been established and 452 this state is established. In this state, an adjacency is established 453 and the FLIP Hello protocol should begin operation over this adjacency. 455 Inputs 456 ------ 458 A - FLIP Reset 459 B - Advertisement from neighbor without receiving device's interface 460 present 461 C - Advertisement from neighbor with receiving device's interface 462 present 463 D - Advertisement received with parameters changed (i.e. re- 464 negotiation) 465 E - FLIPAdvertisementDeadInterval expires 467 Actions 469 Sandick, Squire, Cain, Duncan, Haberman 9 470 ------- 472 a - Reset FLIPAdvertisementDeadInterval timer 473 b - Multicast a FLIPAdvertisement on interface having added the 474 neighbor interface address to the list of the list of Neighbor 475 Interfaces; set FLIPAdvertisementDeadInterval timer; reset the 476 FLIPAdvertisementInterval timer; adjacency established; begin FLIP 477 Hello protocol 478 c - Update operational parameters for FLIP Hello message exchange; 479 unicast FLIPNewAdvertisements number of FLIP advertisements to 480 neighbor; reset the FLIPAdvertisementInterval timer; reset 481 FLIPAdvertisementDeadInterval; 482 d - Stop FLIPAdvertisementDeadInterval timer; multicast a 483 FLIPAdvertisement on interface; reset the FLIPAdvertisementInterval 484 timer; stop FLIP Hello exchange; 485 e - stop FLIP Hello exchange 486 n - no op 487 NA - Not applicable 489 5 FLIP Hello Protocol 491 5.1 Protocol Description 493 The FLIP Hello protocol is used as a fast keepalive protocol for 494 determining the status of neighbor adjacencies. This protocol is 495 designed to operate at high frequencies for quickly detecting link and 496 device failures. An implementation may choose to implement this 497 protocol in hardware in order to achieve the high frequency rates 498 required to send and receive hello messages. 500 The FLIP Hello is a simple fixed format message exchanged by devices. 501 After a neighbor adjacency has been established via the FLIP 502 Advertisement protocol and parameter negotiations have resolved, a 503 device sends unicast FLIP Hello messages to the neighbor interface. 504 The Hellos MUST be sent every HelloInterval. Each device SHOULD apply 505 a small jitter factor to the HelloInterval, rendering the actual 506 parameter to between 75% and 100% of the selected value. The same 507 jitter should be applied to the PeerDeadInterval. The jitter should be 508 calculated once at the beginning of the hello exchange and used until 509 the neighbor adjacency has failed. 511 FLIP Hello messages contain a bit for detecting bi-directional 512 connectivity. If the device has received a hello message from this 513 neighbor adjacency within the last PeerDeadInterval, it sets the 514 HelloHeard bit in the hello messages sent back to that neighbor 515 interface. This bit will set as long as a Hello message has been 516 received from the neighbor interface within the PeerDeadInterval. If 517 the received message has the HelloHeard bit set, then there is 518 successful bi-directional communication with this neighbor, and the 519 neighbor interface is considered to be active. 521 Sandick, Squire, Cain, Duncan, Haberman 10 522 A device must receive a Hello message from a neighbor interface with 523 the HelloHeard bit set within the PeerDeadInterval or, it considers 524 that neighbor adjacency to be down. If connectivity is lost, a FLIP 525 protocol implementation should signal a neighbor adjacency failure. 526 How this information is propagated within a device is an implementation 527 issue and beyond the scope of this document. 529 5.2 Hello Message Contents 531 The FLIP Hello message is a fixed format message, designed to be 532 lightweight and therefore simple enough to be processed in hardware 533 with minimal effort. Therefore, it carries limited information. 535 The FLIP Hello message is carried in an IP packet with IP protocol type 536 X. The source address in the IP header is the address that the sending 537 device uses for the interface that it is transmitting on. The 538 destination address is the source address from the neighbor's FLIP 539 Advertisement. In the case of unnumbered interfaces the source and 540 destination addresses are both set to "0.0.0.0". For Differentiated 541 Service aware networks the DS field will be set in accordance with the 542 Differentiated Services architecture to CS6, b'110xxx [RFC2476]. 544 The body of the packet contains a 4-byte bit field. The first bit is 545 the HelloHeard bit, and indicates that the sender has received a hello 546 message from the this neighbor within the PeerDeadInterval. All other 547 bits are reserved at this time. A valid FLIP Hello is one which: 548 1. IP Protocol Type = X 549 2. ?? 551 5.3 Finite state machine for Hello Message Exchange 553 This finite state machine specifies the protocol for a hello exchange 554 with one neighbor interface. 556 Sandick, Squire, Cain, Duncan, Haberman 11 557 State 558 | | | | | 559 Input | 0 | 1 | 2 | 3 | 560 ------+------+------+------+------+ 561 | | | | | 562 | | | | | 563 A | 1(a )| -(n )| -(n )| -(n )| 564 ------+------+------+------+------+ 565 | | | | | 566 | | | | | 567 B | -(n )| 3(c)| 3(c)| -(f)| 568 ------+------+------+------+------+ 569 | | | | 2(d)| 570 | | | | -or- | 571 C | -(n )| 2(n)| -(n)| -(n )| 572 ------+------+------+------+------+ 573 | | | | | 574 | | | | | 575 D | NA | NA | NA | 1(e)| 576 ------+------+------+------+------+ 577 | | | | | 578 | | | | | 579 E | -(n )| 0(g )| 0(g)| 0(e)| 580 ------+------+------+------+------+ 581 | | | | | 582 | | | | | 583 F | NA | -(a )| -(b )| -(b)| 584 ------+------+------+------+------+ 586 States 587 -------- 589 0 - Reset 590 1 - Neighbor Adjacency established 591 2 - Hello received with HelloHeard bit Off 592 3 - Hello received with HelloHeard bit On: 593 Bi-directional connectivity established 595 Inputs 596 ------ 598 A _ Neighbor Adjacency established 599 B - Hello HelloHeard bit On 600 C - Hello HelloHeard bit Off 601 D - PeerDeadInterval Pops 602 E _ Neighbor Adjacency failed 603 F - HelloInterval pops 605 Sandick, Squire, Cain, Duncan, Haberman 12 606 Actions 607 ------- 609 a - Send hello with HelloHeard bit off; reset HelloInterval timer 610 b - Send hello with HelloHeard bit on; reset HelloInterval timer 611 c - Indicate two-way connectivity has been established; 612 reset PeerDeadInterval timer 613 d - Indicate two-way connectivity has been 614 lost; stop PeerDeadInterval timer 615 e - Indicate two-way connectivity has been 616 lost. Stop PeerDeadInterval timer 617 timer; stop HelloInterval timer 618 f - Reset PeerDeadInterval timer 619 g - Stop HelloInterval timer 620 f - Reset PeerDeadInterval timer 621 n - Do nothing 622 NA- Not applicable 624 6 Hello Exchange over NBMA links 626 TDB 628 7 Default Values 630 The following describes the values and ranges of the variables and 631 timers used in the FLIP protocol. 633 7.1 All-FLIP-Peers 635 The All-FLIP-Peers multicast address has the following possible values: 637 o IPv4 _ 224.0.0.12 638 o IPv6 _ FF02:0:0:0:0:0:0:C 640 7.2 HelloInterval 642 The HelloInterval indicates how often FLIP Hello Messages are 643 transmitted on an interface. The lower bound on the HelloInterval is 1 644 ms. Default value: 3 ms. 646 7.3 PeerDeadInterval 648 Sandick, Squire, Cain, Duncan, Haberman 13 649 The PeerDeadInterval specifies the amount of time a device should wait, 650 since the last Hello message, before declaring a neighbor down. The 651 PeerDeadInterval has a lower bound of 3*HelloInterval and an upper 652 bound of 2^32 ms. Default value: 12 ms. 654 7.4 FLIPAdvertisementInterval 656 The FLIPAdvertisementInterval controls how often FLIP Advertisements 657 are sent. The lower bound on the interval is 3 seconds. The upper 658 bound is 1800 seconds. Default value: 600 seconds. 660 7.5 FLIPNewAdvertisement 662 The FLIPNewAdvertisement variable specifies how many advertisements 663 must be sent upon the activation of an IP interface. The lower bound 664 is 2 and the upper bound is 10. This variable should be tuned to 665 correspond to the loss characteristics of the media. All devices on an 666 IP subnet should have this variable configured the same. Default 667 value: 3. 669 7.6 FLIPAdvertisementDeadInterval 671 The FLIPAdvertisementDeadInterval is the amount time that can elapse 672 without an advertisement being received with the receiving devices IP 673 address in the list of neighbors. The lower bound is 674 [FLIPAdvertismentInterval]. Default value: 675 2*FLIPAdvertisementInterval. 677 7.7 FLIPNewAdvertisementInterval 679 The FLIPNewAdvertisementInterval specifies the timeframe in which the 680 [FLIPNewAdvertisement] advertisements must be sent. Default value: 681 [FLIPNewAdvertisment] seconds. 683 8 Security Considerations 685 TBD. 687 9 Intellectual Property Considerations 689 Nortel Networks may seek patent or other intellectual property 690 protection for some or all of the technologies disclosed in this 691 document. If any standards arising from this document are or become 692 protected by one or more patents assigned to Nortel Networks, Nortel 693 intends to disclose those patents and license them on reasonable and 694 non-discriminatory terms. 696 Sandick, Squire, Cain, Duncan, Haberman 14 697 10 References 699 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 700 1256, September 1991. 702 [IANAAFN] IANA Address Family Number, http://www.isi.edu/in- 703 notes/iana/assignments/address-family-numbers. 704 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 705 "Definition of the Differentiated Services Field 706 (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, 707 December 1998. 709 Appendices 711 A. 712 Setting the HelloInterval 714 There are three factors that affect the bandwidth utilization of FFLIP 715 Hello messages. First, is the HelloInterval or the frequency with 716 which the messages are sent. The second factor is the speed of the 717 link. The third factor is how many neighbor adjacencies are maintained 718 over one link (for multi-access links only). Let t represent the 719 number of milliseconds between hello packets, m represent the Mbps 720 available to L2 data over that link, p represent the size of the hello 721 packet in bits at Layer 2, and n represent the number of devices 722 sharing the bandwidth over that link. The general formula to determine 723 the percentage of the Layer 2 bandwidth used by the hello messages 724 between the n peers over that link: 726 pn(n-1) 727 Bandwidth percentage = -------- 728 10tm 730 For full duplex links, this percentage should be divided by two. 732 The following table shows how much bandwidth a 64-byte Hello message 733 uses over various media speeds and hello intervals. Full duplex 734 communication is assumed for a single pair of neighbors. Note: 64-byte 735 size packet is selected because it is the minimum size on Ethernet 736 subnets. 738 Sandick, Squire, Cain, Duncan, Haberman 15 739 millisecond = ms 741 Percentage of link for 64-byte packet 742 transmitted every time period 744 10Mb 100Mb 1Gigb 745 +------+--------+----------+----------+ 746 3ms | 64 B | 1.7& | .17% | .017% | 747 +------+--------+----------+----------+ 748 6ms | 64 B | .85% | .085% | .0085% | 749 +------+--------+----------+----------+ 750 9ms | 64 B | .57% | .057% | .0057% | 751 +------+--------+----------+----------+ 752 12ms | 64 B | .43% | .043% | .0043% | 753 +------+--------+----------+----------+ 754 | . | 755 | . | 756 | . | 758 These numbers must be multiplied for each neighbor adjacency maintained 759 over an interface. So for example if there are 10 peers over a 100 Mb 760 interface sending hellos every 9ms would use .57% over switched full 761 duplex and 1.1 % over switched half duplex and 12.54% over a shared 762 media. 764 There are several factors to consider when setting the HelloInterval 765 and the PeerDeadInterval: speed of the link, quality of the link, timer 766 precision, number of neighbors, etc. Additionally, if there is a self 767 healing subnet technology in the middle of the subnet, the timers may 768 set with a large enough interval to allow the subnet to fix the link 769 fault before FFLIP events determine a neighbor adjacency failure to be 770 down. 772 B. 773 Formats 775 B.1 FLIP Advertisement Message 777 Sandick, Squire, Cain, Duncan, Haberman 16 778 0 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Type | Code | Checksum | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Hello Interval | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | PeerDeadInterval | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | GroupID | Reserved | Address Family Number | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | PeerID | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Neighbor Interface #1 | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | . . . | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Neighbor Interface #X | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 IP Fields: 800 Source Address An IP address belonging to the interface 801 from which this message is sent. 803 Destination Address The configured multicast Advertisement 804 Address or the IP address of a 805 neighboring host. 807 Time-to-Live 1 809 ICMP Fields: 811 Type X 813 Code 0 {FLIP Advertisement) 815 Checksum The 16-bit one's complement of the one's 816 complement sum of the ICMP message, 817 starting with the ICMP Type. For 818 computing the checksum, the checksum 819 field is set to 0. 821 HI HelloInterval _ This interval is the time 822 period between successive FLIP Hello 823 messages. Measured in milliseconds 825 Sandick, Squire, Cain, Duncan, Haberman 17 826 PDI PeerDeadInterval _ If this device does 827 not receive a FFLIP Hello message from 828 the neighbor interface within this time 829 period, it will consider the link to be 830 down. Measured in milliseconds. 832 GroupID Identifies a particular set of peers, 833 e.g. routers. 835 Reserved must be all zeros 837 Address Family Number 0 Reserved 838 1 IP (IP version 4) 839 2 IP6 (IP version 6) 841 PeerID The sending peer's globally unique IP 842 identifier. 843 Length is per Address Family. 845 Neighbor Interface X A list of all source IP addresses of all 846 FLIP Advertisements that have been heard 847 on this interface. Length of each 848 address is per Address Family. 850 B.2 FLIP Solicitation Message 852 The message is the same format as the FLIP Advertisement. The fields 853 are set the same with the following exceptions: 855 IP Fields: 857 Destination Address The configured multicast Advertisement 859 ICMP Fields: 861 Type X 863 Code 1 {FLIP Solicitation) 865 Neighbor Interface X A list of all source IP addresses of all 866 FLIP Advertisements that have been heard 867 on this interface. The field should be 868 empty and MUST be ignored by the 869 receiving device 871 Sandick, Squire, Cain, Duncan, Haberman 18 872 B.3 FFLIP Hello Message 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | | 878 | IP Header | 879 | | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 |H| Reserved | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 IP Fields: 886 DSCP This is the Differential Services Code Point. If supported set 887 to CS6, b'110xxx 888 Source Address An IP address belonging to the interface 889 from which this message is sent. 891 Destination Address The IP address of a neighboring host. 893 Time-to-Live 1 895 IP Protocol Type FFLIP Protocol (type X) 897 Hello Fields: 899 H Bit HelloHeard bit. The transmitting device 900 has received a hello message from the 901 target of this message. 903 Reserved set to all zeros 905 Authors' Addresses 907 Hal Sandick 908 Nortel Networks 909 4309 Emperor Blvd 910 Suite 200 911 Durham, NC 27703 912 email: hsandick@nortelnetworks.com 914 Matt Squire 915 Nortel Networks 916 4309 Emperor Blvd 917 Suite 200 918 Durham, NC 27703 920 Sandick, Squire, Cain, Duncan, Haberman 19 921 email: msquire@nortelnetworks.com 923 Brad Cain 924 Nortel Networks 925 600 Technology Park 926 Billerica, MA 01821 927 Email: bcain@nortelnetworks.com 929 Brian Haberman 930 Nortel Networks 931 4309 Emperor Blvd 932 Suite 200 933 Durham, NC 27703 934 email: haberman@nortelnetworks.com 936 Ian Duncan 937 Nortel Networks 938 130 COLONNADE ROAD 939 NEPEAN, ONTARIO K2E 1B6 940 email: iduncan@nortelnetworks.com 942 Sandick, Squire, Cain, Duncan, Haberman 20