idnits 2.17.1 draft-palanivelan-bfd-v2-gr-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Nov 17, 2011) is 4537 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5306 (ref. 'IS-IS-GRACE') (Obsoleted by RFC 8706) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT A.Palanivelan 3 Intended Status: Historic EMC Corporation 4 Expires: May 20, 2012 Nov 17, 2011 6 A Record of Discussions of Graceful Restart Extensions for 7 Bidirectional Forwarding Detection (BFD) 8 draft-palanivelan-bfd-v2-gr-13 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright and License Notice 33 Copyright (c) 2011 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Abstract 48 This document is a historical record of discussions about extending 49 the Bidirectional Forwarding Detection (BFD) protocol to provide 50 additional capabilities to handle Graceful Restart. 52 These discussions took place in the context of the IETF's BFD working 53 group, and the consensus in that group was that these extensions 54 should not be made. 56 This document presents a summary of the challenges to BFD in 57 surviving a graceful restart, and outlines a potential protocol 58 solution that was discussed and rejected within the BFD working 59 group. The purpose of this document is to provide a record of the 60 work done so that future effort will not be wasted. This document 61 does not propose or document any extensions to BFD, and there is no 62 intention that it should be implemented in its current form. 64 Table of Contents 66 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1 Restarts with control protocols . . . . . . . . . . . . . . 4 70 3.2 BFD Co-existing with Broadband configurations . . . . . . . 5 71 4. Extensions to BFD . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1 Diagnostic (Diag) . . . . . . . . . . . . . . . . . . . . . 6 73 4.2 State (Sta) . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.3 My Restart Interval . . . . . . . . . . . . . . . . . . . . 7 75 4.4 Your Restart Interval . . . . . . . . . . . . . . . . . . . 7 76 5. State Machine for BFD with GR Support . . . . . . . . . . . . . 8 77 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . . 10 78 6.1. Session Establishment and GR Timer exchange . . . . . . . . 10 79 6.2. Remote Neighbor Restart and Recovery . . . . . . . . . . . 11 80 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 81 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 82 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 13 83 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 10.1 Normative References . . . . . . . . . . . . . . . . . . . 13 85 10.2 Informative References . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1 Introduction 90 The Bidirectional Forwarding Detection protocol [BFD] provides 91 mechanism for liveness detection of arbitrary paths between systems. 92 It is intended to provide low-overhead, short-duration detection of 93 failures in the path between adjacent forwarding engines, including 94 the interfaces, data links, and to the extent possible, the 95 forwarding engines themselves. It operates independently of media, 96 data protocols, and routing protocols. An additional BFD goal is to 97 provide a single mechanism that can be used for liveness detection 98 over any media, at any protocol layer, with a wide range of detection 99 times and overhead, to avoid a proliferation of different methods. 101 Graceful Restart (GR) was considered for BFD, but was rejected by the 102 BFD Working Group as unnecessary and potentially detrimental to the 103 protocol. As a result, the work on BFD GR was not progressed within 104 the working group. 106 This document presents a summary of the challenges to BFD in 107 surviving a graceful restart, and outlines a potential protocol 108 solution that was discussed and rejected within the BFD working 109 group. The purpose of this document is to provide a record of the 110 work done so that future effort will not be wasted. 112 This document does not propose or document any extensions to BFD, and 113 there is no intention that it should be implemented in its current 114 form. 116 2 Overview 118 The Bidirectional Forwarding Detection [BFD] specification defines a 119 protocol with simple and specific semantics. Its purpose is to verify 120 liveliness of the connectivity between a pair of systems, for a 121 particular data protocol across a path (which may be of any 122 technology, length, or at any protocol layer). The promptness of the 123 detection of a path failure can be controlled by trading off protocol 124 overhead and system load with detection times. 126 BFD works properly without a need for any GR support. The author is 127 aware of BFD implementations that have experienced problems 128 maintaining liveliness verification during GR. It is true that 129 prioritizing BFD would make sure the other CPU intensive processes do 130 not cause BFD to fail, but this may not be possible in some 131 implementations as there may be other higher priority processing that 132 can't be ignored. For example, perhaps existing subscriber 133 connections can't be given a lesser priority. 135 3 Motivations 137 This section of the document discusses the following issues, might be 138 seen in BFD deployments: 140 * Restarts with control protocols 142 * BFD co-existing with Broadband configurations 144 The later sections of this document capture ideas about protocol 145 extensions that attempted to provide a general GR mechanism for BFD, 146 but were rejected by the working group as unnecessary and 147 inappropriate. The working group believes that the existing BFD 148 design has the capabilities to take care of these challenges. 150 3.1 Restarts with control protocols 152 Section 4.3 of [RFC5882] describes how BFD can interact with the GR 153 of control plane protocols. 155 Some protocols can signal the intention to perform a restart before 156 initiating the restart, and can indicate when the restart has been 157 completed. In these cases, [RFC5882] recommends that the restart 158 should not be aborted and no topology change should be signalled in 159 the control plane if BFD detects a session failure during the 160 restart. 162 Control protocols that cannot signal a planned restart must treat 163 planned and unplanned restarts in the same way. In order to avoid 164 treating a BFD failure being triggered by the restart and causing the 165 restart to be aborted or the topology modified, such protocols depend 166 on the restarting system signalling the existence of the restart 167 event before BFD detects the failure (for example, before the BFD 168 session times out). 170 In most cases, whether the restart is planned or unplanned, it is 171 likely that the BFD session timeout will be shorter that the restart 172 time up to the point where the Graceful Restart event can be 173 signalled. Thus, if there is an interruption to BFD caused by the 174 restart, BFD will detect a fault and cause a topology change to be 175 signaled. That means there could be an issue in implementations where 176 a control plane restart event causes BFD to be disrupted. Such a 177 situation could impact non-stop routing and non-stop forwarding 178 support using GR-enabled protocols. 180 In considering this situation, the BFD working group determined that 181 the solution was to implement the system such that a protocol restart 182 would not cause disruption to the function of the BFD session. Such 183 could easily be achieved by maintaining the BFD session in the 184 forwarding hardware. In arriving at this determination, the working 185 group realized that any restart event that disrupted the BFD 186 processes in the forwarding hardware would also result in a 187 disruption to forwarding and it would, therefore, be correct to allow 188 BFD to report the failure. 190 3.2 BFD Co-existing with Broadband configurations 192 Assume a Provider-Edge (PE) router may have active DHCP sessions with 193 a large number of clients (say 16k). During a planned restart of the 194 PE, it is possible that a number of the DHCP clients will request the 195 server (restarting router) to renew client IP addresses. These 196 requests will be retried and will reach the router in bulk after it 197 has just come up. The router might be implemented to treat them at a 198 high priority and respond to them. When there are thousands of such 199 requests to the restarting router, the router might spend a major 200 part of its first second of up time addressing them. 202 In this scenario, a control protocol like OSPFv2 that has GR enabled 203 [OSPF-GRACE], could withstand the restart for the specified restart 204 interval (as it will be in seconds) and it is likely to survive the 205 restart, maintaining its forwarding plane. 207 In the same scenario, if BFD is enabled for OSPFv2 for an unplanned 208 restart, the (BFD) neighbor router will be expecting BFD control 209 packets in a milliseconds interval; during the restart process it 210 could timeout, which would also impact the associated OSPFv2 211 adjacency and result in loss of traffic. 213 The scenario will be the same for BFD with a protocol such as IS-IS 214 [IS-IS-GRACE], where the problem would be seen even for a planned 215 restart since there is no ability to signal the restart event. 217 In its consideration of this scenario, the BFD working group decided 218 that the situation would only arise if the PE router implementation 219 gave disproportionate resources to other processes in such a way as 220 to impact BFD. The working group considered that a sensible 221 implementation would not lead to the problems described in this 222 section. 224 4. Extensions to BFD 226 The protocol elements described in this section were rejected by the 227 BFD working group and should not be implemented. The protocol 228 procedures are not complete and the message formats do not form part 229 of any BFD specification. 231 In discussions of a potential BFD protocol solution to circumvent the 232 issues described in Section 3, a proposal was made to introduce a new 233 BFD diag value to indicate that the neighbor is restarting, and 234 provisions to configure BFD Graceful Restart timers. 236 The Generic BFD Control Packet [BFD] format shown below includes two 237 additional fields "My Restart Interval" and "Your Restart Interval". 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | My Discriminator | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Your Discriminator | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Desired Min TX Interval | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Required Min RX Interval | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Required Min Echo RX Interval | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | My Restart Interval | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Your Restart Interval | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 4.1 Diagnostic (Diag) 261 A diagnostic code specifying the local system's reason for the last 262 change in session state. This field allows remote systems to 263 determine the reason that the previous session failed. Values for 264 this field are allocated by IANA according to Expert Review 265 [RFC5226]. The procedures discussed, rejected and recorded in this 266 document include a new diag value to represent "Neighbor Restarting". 268 4.2 State (Sta) 270 The procedures discussed, rejected and recorded in this document 271 include a new BFD session state, "NeighborRestart". 273 The current session state is signalled in the Sta field [BFD]. This 274 is a two-bit field and [BFD] defines all four possible values for the 275 field. No mechanism was discussed or agreed upon within the BFD 276 working group for how this additional session state would be 277 signalled. A proposal to use the value 4 in the two-bit field was 278 considered impractical. 280 4.3 My Restart Interval 282 The procedures discussed, rejected and recorded in this document 283 include the addition of a My Restart Interval field to the BFD 284 message as shown in the figure in Section 4. 286 This is the restart interval, in microseconds, of the transmitting 287 system advertised to the remote system. In the case of a restart (of 288 the transmitting system), the remote system is expected to keep the 289 BFD session up for this duration of time. This field needs to have a 290 value greater than the detection time (see section 6.2). A value of 291 0 indicates to the remote system that this system has BFD-GR 292 disabled. The Length (L) field in the BFD header that indicates the 293 fixed header length, would include the length of this field if this 294 field were present. 296 4.4 Your Restart Interval 298 The proposed procedures discussed, rejected and recorded in this 299 document include the addition of a Your Restart Interval field to the 300 BFD message as shown in the figure in Section 4. 302 This is the restart interval, in microseconds, received from the 303 corresponding remote system. In the case of a restart (of the remote 304 system), the transmitting system is expected to keep the BFD session 305 up for this duration of time. This field needs to have a value 306 greater than the detection time. The Length (L) field in the BFD 307 header that indicates the fixed header length, would include the 308 length of this field, if this field were present. 310 5. State Machine for BFD with GR Support 312 The BFD state machine is quite straightforward and explained in 313 detail by [BFD]. [BFD] describes different states for BFD as: Down, 314 Init, Up, AdminDown. 316 Each system communicates its session state in the State (Sta) field 317 of the BFD Control packet, and that received state, in combination 318 with the local session state, drives the state machine.Please refer 319 to [BFD] for state the machine diagram and detailed explanations of 320 the state transitions. 322 The following diagram provides an overview of the state machine, for 323 state transitions for BFD with GR support (where "Your Restart 324 Interval" has a non-zero value greater than Detection time). This 325 document introduces a new state, "NeighborRestart" to the BFD state 326 machine. The use of that new state has not been adopted by the BFD 327 working group and should not be included in implementations. 329 Furthermore, as noted in Section 4.2, no mechanism exists or has been 330 proposed for communicating this additional state to a BFD peer. 331 Therefore, it must be recognized that the state machine shown here is 332 purely hypothetical and that all procedures described do not form 333 part of the BFD specification. 335 The "Your Restart Interval" must have a value greater than the 336 detection time value. If this value is zero or less than the 337 detection time value, the state transitions should completely follow 338 the BFD state machine as defined by [BFD]. 340 The notation on each arc represents the state of the remote system 341 (as received in the State field in the BFD Control packet) or 342 indicates the expiration of the Detection Timer. 344 +-----+ 345 | | INIT, UP 346 | v 347 +-----------------------------+ 348 +-------->|State = UP, Diag = 0, | 349 | |Timer = "Detect Interval" |<----+ 350 | | | | 351 | +-----------------------------+ | 352 | | | | 353 | | | | 354 | | {Neighbor Restart} | 355 | | | | 356 | | | | 357 |INIT,UP | | {Neighbor Restart 358 | | | complete} 359 | | | | 360 | | v | 361 +-------+ | +---------------------------------+ 362 +-----| | | |State = NEIGHBORRESTART, | 363 | | | | |Timer = "Your Restart interval" | 364 DOWN | | INIT | | +---------------------------------+ 365 +---->| | | | 366 +-------+ |ADMIN DOWN, | 367 | |DOWN, | 368 | |TIMER | 369 | v ADMIN DOWN,| 370 | +-------+ DOWN,| 371 | | | TIMER | 372 ADMIN DOWN,| | DOWN |<---------------+ 373 TIMER | | | 374 +------>| | 375 +-------+ 376 | ^ 377 | | UP, ADMIN DOWN, TIMER 378 | | 379 +---+ 381 Note1: This state diagram holds only for BFD with GR extension as 382 described in this document, which implies that "your Restart 383 Interval" has a value greater than the Detection time value of the 384 established session. This state machine must not be implemented. 386 Note2: The labels of the diagram in braces {} indicate the GR 387 Specific events on the remote neighbor (Restart/Restart complete). 389 The State Transitions involving the new state, NeighborRestart is 390 explained in the next section of this document. 392 6. Theory of Operation 394 This section describes the possible operation of the protocol 395 elements and state machine described in the previous sections. The 396 processes described here were discussed and rejected by the BFD 397 working group. In particular, the processes presented are specific to 398 the GR and are not complete. The BFD Working group does not recommend 399 these processes for implementation and must not form part of a 400 deployed BFD system. 402 6.1. Session Establishment and GR Timer exchange 404 The BFD session establishment follows the procedures as described 405 in[BFD]. If the technology described by this document were to be 406 implemented, the BFD control packets would have the following fields 407 with the values given below. 409 A new section to the BFD control packet format, "My Restart Interval" 410 (Section 4.3) needs to have a non-zero value that is greater than the 411 detection time. 413 A new section to the BFD control packet format, "Your Restart 414 Interval" (Section 4.4) needs to have a non-zero value that is 415 greater than the detection time. 417 The "My Restart Interval" and "Your Restart Interval" are used in 418 exchanging the GR timers information between the systems. 420 "My Restart Interval" is the time interval in microseconds, that 421 this system expects its remote system to wait for before bringing 422 down its BFD session with that system. 424 "Your Restart Interval" is the time interval in microseconds, 425 specified by the remote system, that it expects this system to wait 426 for, before bringing down its BFD session with the remote system. 428 Once the packet exchanges are complete and the BFD sessions are 429 up,every BFD session will have information about the time interval 430 its remote system will wait during a Restart, and also the time 431 interval this system has to wait when the remote system restarts. The 432 "My Restart Interval" and the "Your Restart Interval" values can be 433 modified after the session is up, just like the other BFD parameters, 434 and in this case the packet exchanges will sync up the restart 435 interval times (My and Your) on both the sides appropriately. 437 The exchange of GR Specific parameters during BFD session 438 establishment is indicated in the diagram below. The diagram shows 439 only part of control packets, for the purpose of clarity. 441 System A System B 442 | | 443 | | 444 |----------------------------------->| 445 | {BFD.MyRestartInterval = AAAA | 446 | BFD.YourRestartInterval = 0 } | 447 | | 448 |<-----------------------------------| 449 | {BFD.MyRestartInterval = BBBB | 450 | BFD.YourRestartInterval= AAAA } | 451 | | 452 |----------------------------------->| 453 | {BFD.MyRestartInterval = AAAA | 454 | BFD.YourRestartInterval= BBBB } | 455 | | 457 The initial BFD packet exchange between local system and remote 458 system will have the exchanged values for the "My Restart Interval" 459 or 0. The "Your Restart Interval" will reflect the value received in 460 My Restart Interval" from the corresponding remote system, or be 461 Zero if that value is not set (value of 0). 463 A value of Zero for "Your Restart Interval" means that the BFD GR is 464 disabled at the remote end, and similarly a value of Zero for "My 465 Restart Interval" means that BFD GR is disabled at the transmitting 466 system. 468 6.2. Remote Neighbor Restart and Recovery 470 When the BFD neighbors have established their BFD sessions (with 471 their BFD GR timer values exchanged as described above), the 472 following set of operations take place when the remote neighbor 473 attempts a graceful restart (for example, with a GR enabled routing 474 protocol like OSPFv2/IS-IS tied with BFD). 476 Once the packet exchanges are complete and the BFD sessions are up, 477 every BFD session will have information about the time interval its 478 remote system will wait during a Restart, and also the time interval 479 this system has to wait when the remote system restarts. 481 For clarity, let us revisit the BFD timers and BFD detection time as 482 described in [BFD]. 484 The Detection Time (the period of time without receiving BFD packets 485 after which the session is determined to have failed) is not carried 486 explicitly in the protocol. Rather, it is calculated independently 487 in each direction by the receiving system based on the negotiated 488 transmit interval and the detection multiplier. 490 This means that a BFD control packet should be received from the 491 remote neighbor within the detection time. When the BFD control 492 packet is not received from the remote neighbor within this time, the 493 timer expiry should bring the BFD session state to down. 495 During a Graceful, we may end up in a situation that the routing 496 protocol (like OSPFv2) is in graceful restart mode with the remote 497 neighbor restarting, and the system not receiving BFD control packets 498 within the detection time, due to other CPU intensive processes in 499 the system. The technology described by this document addresses this 500 issue. 502 If the set of systems had their BFD sessions established, with GR 503 support as described in this document, when the remote neighbor 504 restarts it will set the BFD diagnostics field to a value to 505 indicate "Neighbor Restarting" in the control packet to its neighbor 506 (local system). 508 When the local system receives a BFD control packet with its diag 509 field set to indicate "Neighbor Restarting", the local system will 510 update its timer to the previously exchanged value of "Your Restart 511 Interval". 513 This effectively means that the local system should wait for a BFD 514 control packet for "Your Restart Interval" instead of Detection time. 515 This will be the case as long as the diag field from the remote 516 neighbor indicates Neighbor Restart. The BFD moves from "Up" to 517 "NeighborRestart" state. 519 7 Security Considerations 521 The security implications of the ideas discussed in this document 522 have not been examined. It is likely that the security considerations 523 discussed in [BFD], [BFD-1HOP] apply to this document. 525 8 IANA Considerations 527 This document is a historical record of the work and the discussions 528 on the BFD working group, on a possible solution to Graceful Restart. 529 No IANA action is requested. 531 9 Acknowledgments 533 The Author likes to acknowledge caldwel.E and Ramesh.M for their 534 early inputs to this document. Thanks to Fred Baker, Dave Ward 535 (bfd-wg Chair), Senthil Sivakumar, Nevil Brownlee (RFC-ISE) and 536 Adrian Farrel (routing AD) for valuable advice, help and guidance. 538 The Author also likes to thank Joel Bion, Karthik, Mridhula, Ramya, 539 and members of ISOC fellowship committee for their wholehearted 541 support towards the author's IETF activities. 543 10 References 545 10.1 Normative References 547 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding 548 Detection",RFC 5880, June, 2010. 550 [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single 551 Hop)", RFC 5881, June, 2010. 553 [RFC5882] Katz, D. and Ward, D., "Bidirectional Forwarding 554 Detection", RFC 5882, June 2010 556 10.2 Informative References 558 [IS-IS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for 559 IS-IS", RFC 5306, October 2008. 561 [OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623, 562 November 2003. 564 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an 565 IANA Considerations Section in RFCs", RFC5226, May 2008. 567 Authors' Addresses 569 Palanivelan Appanasamy 570 Principal Software Engineer, 571 Networking/WAN, EMC Corporation, 572 Bangalore-560048. 573 India. 575 EMail: Palanivelan.Appanasamy@emc.com