idnits 2.17.1 draft-ansari-forces-discovery-01.txt: -(152): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(237): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(351): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(364): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(496): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(604): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(606): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 19. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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? == There are 21 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 28 has weird spacing: '... at any ti...' == Line 29 has weird spacing: '...ference mater...' == Line 32 has weird spacing: '... The list ...' == Line 48 has weird spacing: '... This docum...' == Line 64 has weird spacing: '.... Full topol...' == (24 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 25, 2004) is 7116 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: 'RFC-2119' is mentioned on line 45, but not defined == Missing Reference: 'RFC 3746' is mentioned on line 92, but not defined == Unused Reference: 'RFC3746' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'OSPF' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'BGP' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 606, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3746 ** Downref: Normative reference to an Informational RFC: RFC 3654 == Outdated reference: A later version (-22) exists of draft-ietf-forces-protocol-00 -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) Summary: 13 errors (**), 0 flaws (~~), 18 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Furquan Ansari 3 Internet Draft Lucent Tech. 4 Document: draft-ansari-forces-discovery-01.txt Hormuzd Khosravi 5 Expires: April 24, 2005 Intel Corp. 6 Working Group: ForCES Jamal Hadi Salim 7 Znyx 8 October 25, 2004 10 ForCES Intra-NE Topology Discovery 12 draft-ansari-forces-discovery-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance 19 with RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as ``work in 30 progress.'' 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire in April 24, 2005. 40 Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 44 this document are to be interpreted as described in [RFC-2119]. 46 Abstract 48 This document describes a mechanism for discovering inter-FE 49 topology and topology maintenance. Such a mechanism is essential for 50 all these elements in the set to behave as a single Network Element, 51 as required by the ForCES architecture as well as to perform certain 52 optimizations at the FE by making use of the topology. The discovery 53 mechanism only operates during post-association phase of ForCES 54 protocol. 56 Table of Contents 57 1. Definitions........................................................2 58 2. Introduction.......................................................2 59 2.1. Motivation....................................................4 60 3. Topology Discovery Mechanism.......................................5 61 3.1. Minimum requirements..........................................6 62 3.2. Protocol Details..............................................6 63 3.2.1. Topology Discovery and Maintenance.......................7 64 3.2.2. Full topology computation at the CE from partial 65 topologies......................................................8 66 3.3. Protocol and Message Headers..................................9 67 3.3.1. TLV definitions.........................................10 68 3.4. Inter-FE Topology Discovery Examples.........................10 69 3.4.1. Forwarding Elements connected in a daisy chain..........11 70 3.4.2. Forwarding Elements connected in a ring.................12 71 4. Security Considerations...........................................13 72 5. References........................................................13 73 5.1. Normative....................................................13 74 5.2. Informative..................................................14 75 6. Authors' Addresses................................................14 76 7. Full Copyright Notice.............................................14 77 8. Acknowledgements..................................................15 79 1. Definitions 81 Inter-FE topology discovery: Topology discovery relates to how the 82 FEs are interconnected with each other with respect to packet 83 forwarding. This is the complete view of the intra-NE network as 84 seen by the CE. 86 Inter-FE topology maintenance: Once the inter-FE topology has been 87 discovered, it has to be continuously monitored to ensure that any 88 changes to the topology are reported to the corresponding CE. This 89 represents the steady state and final phase of the protocol. 91 2. Introduction 92 The ForCES framework document [RFC 3746] describes how a set of 93 control elements (CEs) and forwarding elements (FEs) interact with 94 each other to form a single network element (NE). It describes the 95 ForCES post-association phase protocol working across the Fp 96 reference point between CE and FE. This document describes an 97 important aspect of the ForCES operational infrastructure, that of 98 discovering the layout of the different elements within an NE. 100 We describe a mechanism for obtaining the Intra-NE/Inter-FE 101 topology. 102 The mechanism is divided into two distinct operational pieces: 103 . The FE side component that collects FE neighbor information. 104 . The CE side component that uses the neighbor information to 105 compute the NE topology. 106 Given the above split, we believe that this mechanism fits well 107 within a description of Topology Discovery LFB. 109 The mechanism at the FE can be divided into two modes or phases. 111 . Phase I corresponds to the actual discovery process wherein each 112 element discovers its neighbor and maintains a neighbor 113 relationship. Upon Joining an NE, the CE will instruct the FE to 114 start collecting this information. This happens when the FE is 115 administratively up and the associated neighbor links are deemed 116 to be provisioned and operationally up. 117 . Phase II corresponds to the topology maintenance phase, wherein 118 any changes to the inter-FE topology during normal operation is 119 reported to the corresponding CE so that an updated view is 120 available. The CE then makes all services it is controlling aware 121 of such details. As an example, based on policy, in a basic IPV4 122 service, the tables of associated FEs will need to be updated. 124 As noted above, both phases occur during the post-association phases 125 of the ForCES protocol. In other words, the ForCES protocol 126 association between the CE and the FEs should already have taken 127 place for the discovery mechanism to kick in. This is required 128 because the neighbor relationships maintained by the FEs are 129 reported back to the CE (or queried by the CE) over the ForCES 130 protocol. 132 The proposed discovery mechanism is required to scale to a very 133 large number of forwarding elements in the NE, with minimal impact 134 on the resources. The following list provides some of the features 135 and goals of the discovery mechanism. 137 . Determine connectivity between elements 138 . React to changes in link connectivity 139 . Construct topology information from the collected partial topology 140 information 141 . Tolerant to protocol message losses 142 . Applicable to all inter-FE network topologies such as ring, mesh, 143 star etc. 144 . Cause minimal overhead 145 . Agnostic of the network interconnect technology 147 2.1. Motivation 149 The ForCES architecture defines a network element (NE) as a single 150 managed entity made up of a collection of FEs and CEs and is 151 indistinguishable from other network elements in the network. This 152 NE model definition leads to three types of links from the network�s 153 perspective: internal (or intra-NE) links and external (or inter-NE) 154 links and control links. Intra-NE links are purely internal to the 155 NE and are not exposed to the external world; whereas, inter-NE (or 156 external) links are exposed to the external world and over which 157 routing adjacencies (such as OSPF, IS-IS, BGP etc.) can be formed. 158 An NE can contain FEs that have zero or more internal/external links 159 � e.g. in Fig. 1, FE3 has two internal links and no external links 160 while FE1 and FE2 have two internal links and one external link 161 each. Control links are those links that are used for communication 162 between the CE and FE. If the CE and FE are a single Layer 3 hop 163 away as in Fig.1, the control link is typically a physical link e.g. 164 link A of FE1 in the figure. Control links can be logical as well. 166 A packet entering a ForCES NE may travel multiple FEs within the NE 167 before it exits onto the output link. This requires that the packet 168 be correctly forwarded from the ingress FE to the egress FE. This 169 internal forwarding requires knowledge of the physical FE inter- 170 connection topology so that the CE can appropriately setup internal 171 LFB tables at each FE to handle packet traversal in a sane manner. 172 We use a simple topology discovery mechanism that only operates on 173 internal links and provides the necessary routing information to 174 forward the packets from the ingress FE to the egress FE. Further, 175 the mechanism should be able to reroute around internal link 176 failures, if a path exists. This makes the NE highly available and 177 resilient. 179 NE 1 180 ..................................... 181 . ----------------- . 182 . | CE | . 183 . ----------------- . ---------- 184 . A ^ B ^ C ^ . | NE 1 | 185 . / | \ . | | 186 . / A v \ . ---------- 187 . / ------- B \ . ^ ^ 188 . / +->| FE3 |<-+ \ . <====> / \ 189 . / |C | | | \ . / \ 190 . A v | ------- | v A . v v 191 . -------B | |D ------- . -------- --------- 192 . | FE1 |<-+ +->| FE2 | . | NE 2 |<---->| NE 3 | 193 . | |<--------------->| | . | | | | 194 . ------- C C ------- . -------- --------- 195 . D^ ^B . 196 .....|.......................|........ 197 | | 198 V v 199 -------- -------- 200 | NE 2 |<--------------->| NE 3 | 201 | | | | 202 -------- -------- 204 (a) (b) 206 Figure 1:(a) illustrates the internal/external links and topology 207 within a NE. (b) Shows the network topology as seen by external 208 routing protocols 210 3. Topology Discovery Mechanism 212 The topology discovery mechanism described here will be restricted 213 to the case where the control and the forwarding elements are a 214 single layer 3 hop away. However, there is no restriction on the 215 number of layer 2 hops between the CE and the FEs. Although, the 216 mechanism can be extended to the multi-hop scenario, it is 217 considered beyond the scope of this document to describe it. The 218 mechanism is expected to work on point-to-point as well as multi- 219 access links. 221 In order to keep the discovery and maintenance mechanism as simple 222 as possible, the FEs only maintain relationships with the respective 223 neighbors to determine the status of the neighbors. No databases are 224 exchanged between the neighbors. This implies that the topology view 225 for each FE is only limited to the adjacent elements. This partial 226 topology information is reported back to the CE (or queried by the 227 CE) over the ForCES protocol. Since the CE receives such information 228 from all the FEs, it can easily construct the full topology from 229 individual partial topologies reported by each FE. Once the CE 230 constructs the full topology, such information can be passed to the 231 FEs, if needed (depending on policy). 233 Topology information is needed by a lot of LFBs and associated 234 services that span multiple FEs within a NE. In the case where the 235 FE aids the CE in offloading the table updates, then it makes sense 236 for the FE to be topology aware. It is sometimes also helpful to 237 keep full topology information at the FEs for cases such as �message 238 snooping� optimizations. For example, if an FE is aware of the 239 topology, it could snoop on messages sent to other FEs (e.g. 240 broadcasts, multicasts) and update its own tables dynamically 241 without involving the CE. Another example would be FE-FE primary- 242 backup handover scenario. With each FE being fully aware of the 243 complete topology, the backup FE can take over the responsibilities 244 of the primary without involving the CE for such a handover. 246 3.1. Minimum requirements 248 In order for the protocol to work as described, the following 249 assumptions are made. 250 . Each element has been configured with their respective IDs 251 (CEID, FEID) 252 . Element bindings process has already taken place. In other 253 words, the CE know all the FEs it wants to control and each FE 254 knows which CE is allowed to control it. 255 . The ForCES protocol association has already taken place between 256 the CE and the FE in question. 257 . The protocol is enabled on the required interfaces. 259 Note that these are configuration requirements and are satisfied by 260 the respective managers (CEM/FEM). 262 3.2. Protocol Details 264 Once the ForCES protocol association has been established between a 265 CE and a given FE � i.e. it is in post-association phase, the CE 266 starts sending/advertising Hello/Probe messages to the FE�s 267 neighbors such that the messages go through the given FE. In other 268 words, it looks like the given FE is generating probe messages to 269 the neighbor (except that these messages are coming from the CE over 270 the ForCES protocol first). However, this functionality of 271 generating probe messages by the CE can be offloaded to the FE 272 itself (to be more precise, to an FE LFB) � so that the FE can 273 originate and terminate the probe messages. This provides better 274 scalability of the CE and it�s resources. The CE can now simply 275 query each FE�s neighbor relationship database and register for any 276 events related to topology changes. 278 All Hello/Probe messages travel a single PE hop and are not routed 279 to other elements beyond the first hop. This is ensured by using a 280 TTL of one on all Hello/Probe packets. The messages are sent as IP 281 datagrams (multicast/broadcast, where applicable, or unicast in 282 general) to the neighboring elements over configured interfaces. 283 Each FE topology LFB component maintains the neighbor relationships 284 as long as the Hello messages are received from the neighbor. If it 285 does not receive a pre-determined number (configured) of back-to- 286 back Hello messages from a given neighbor, it deletes the entry from 287 the database and reports this change to the CE in the form of an 288 event-driven message over the ForCES protocol. This ensures that the 289 CE has the complete and up-to-date information of the underlying 290 topology of the Inter-FE network. 292 The Hello message contains information necessary for discovering and 293 maintaining neighbor relationships. It contains the PE ID, type of 294 protocol element (i.e. CE or FE), interval between any two messages, 295 interval for deeming a neighbor inactive, capability information 296 etc. This is, in some ways, similar to the capabilities of the OSPF 297 Hello protocol. 299 On receiving the Hello messages from a neighbor, the FE responds 300 back with its own Hello message in a packet format similar to the 301 one received from the neighbor. Essentially, both sides are 302 independently sending Hello messages to each other and listing their 303 neighbor table. Also, each neighbor will see itself listed on its 304 neighbors Hello message. This ensures bi-directionality of the link 305 between any two neighbors. 307 The operation is concisely described by the following steps: 308 . CE activates the topology LFB/component on the FE to initialize on 309 specific ports 310 . FE topology LFB/component sends neighbor probes/hellos 311 . CE queries FE for its neighbors 312 . FE continues to send these probes afterwards (maintenance) and 313 updates asynchronously any new updates 315 3.2.1. Topology Discovery and Maintenance 317 Since the CE needs to maintain consistent and up-to-date view of the 318 inter-FE topology, it needs to obtain real-time information of the 319 status of the internal links connecting the FEs. Since the topology 320 discovery and maintenance occurs during the post-association phase, 321 we make use of the event-notification and query/response messages 322 [ForCESP] of the ForCES protocol to provide this information to the 323 CE. It is important to note that each FE only maintains partial 324 topology information obtained through neighbor relationship 325 maintenance through Hello messages. The partial topology view seen 326 by each FE is only the neighbor connectivity information. The CE has 327 to derive the complete topology view of the interconnected FEs based 328 on the partial topology information reported by each FE (or queried 329 by the CE). This ensures that that only the CE maintains all the 330 intelligence and the protocol operation on the FEs is very simple 331 and has minimal overhead. However, as mentioned above, if 332 optimizations can be performed by having the complete topology 333 information available at the FEs, the CE can push such information 334 to any FE interested in it (interest on the FE may be shown in the 335 form of policy configuration). This is an optional feature available 336 on each FE, which can be turned on or off through configuration or 337 during capability exchange negotiation at setup time. Each FE vendor 338 may decide to make use of this feature in different ways, so the 339 capability to obtain such topology information should exist. 341 The periodic Hello messages maintain PE neighbor relationships. 342 Any change in the link or neighbor status causes the FE to generate 343 an asynchronous/event-driven message to the CE indicating this 344 change. The mechanism defined in [ForCESP] is used for delivering 345 event-driven messages from the FE to the CE. This involves the CE 346 subscribing to such event-driven messages from the FE. 348 The CE aggregates the partial topology information received from 349 each FE and generates the inter-FE topology. With this complete 350 knowledge of the inter-FE topology, it can now make appropriate 351 updates to the LFB tables on each FE to move packets inside the NE � 352 from ingress FE to egress FE, assuming that the destination of the 353 packet is not the current NE itself. Any changes in the internal 354 link states (and hence the topology) requires that the CE 355 reconfigure the LFB tables on the FEs based on the most up-to-date 356 information to ensure that the packets do not end up in a black hole 357 or enter a loop. 359 3.2.2. Full topology computation at the CE from partial topologies 361 The CE receives neighbor relationships information from each FE that 362 it uses to construct the full topology of the internal network. Each 363 FE�s neighbor relationship table contains information regarding the 364 local element ID, local port connecting the neighbor, the neighbor�s 365 ID, the neighbor�s port and any optional additional information. 366 Note that the fact that the FE already knows the neighbor�s port 367 information implies that it received the probe/hello messages from 368 the neighbor on that port in response to the hello sent and was, 369 therefore, able to establish bi-directionality of the link. If all 370 the links in the internal network are point-to-point links, the CE 371 simply has to aggregate all the neighbor relationship tables 372 obtained from all the FEs to generate the full topology. If we 373 assume the topology to be a graph, each edge of the graph will be 374 present twice � essentially providing the same information from the 375 two endpoints of the graph. After deleting all the duplicate entries 376 (and thus reducing the table size by half), the CE now has accurate 377 view of the full topology. Please refer section 3.4 [Fig. 3(b)] for 378 more details. 380 [Sub-section on generating full topology from partial topology 381 information for broadcast/multi-access, point-to-multipoint etc. 382 type of links] 384 3.3. Protocol and Message Headers 386 The protocol message consists of a fixed length header (16 bytes) 387 followed by one or more optional TLVs. The format of the message is 388 as follows. 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Version | Flags | Packet Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Checksum | Port ID | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | PE ID | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | TLV-Type | TLV-Length | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | TLV-Value ... | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | ... | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Figure (2) 408 Version: Version number of this protocol. Currently acceptable value 409 is 0x01 411 Flags: These indicate whether the message is sent by a FE, (0x01) or 412 CE (0x02). More options may be defined in the future. 414 Packet Length: The length of the protocol message in bytes, 415 including the header and the following TLVs. 417 Checksum: 16-bit checksum for the protocol message. The checksum 418 calculation does not include the IP header. 420 Port ID: This indicates the port on which this packet was sent out 421 by the sender � useful for topology construction. 423 PE ID: This is the 32-bit identifier of the sender. It could either 424 be CE ID or FE ID, depending on the sender. 426 The protocol header is followed by one or many TLVs. The following 427 TLVs types are defined: 429 Hello TLV: Indicates the Hello message as exchanged by the 430 neighbors. The TLV defines the common hello parameters such as the 431 Hello Interval, Hold time, Uni-directional targeted Hellos, Sequence 432 space number, if needed etc. 434 Capabilities TLV: Provides the capabilities information - TBD 436 Vendor specific TLV: TBD 438 3.3.1. TLV definitions 439 TBD 441 3.4. Inter-FE Topology Discovery Examples 443 The following examples illustrate the topology discovery mechanism. 444 For sake of simplicity, we assume that there is only one CE per NE. 445 The FEIDs of the FEs in the topologies below are FE1, FE2, FE3, and 446 FE4. Each FE has port IDs labeled alphabetically. This is also the 447 case with the CE. 449 ----------------- 450 | CE | 451 ----------------- 452 A ^ B ^ C ^ 453 / | \ 454 / A v \ 455 / ------- B \ 456 / +->| FE3 |<-+ \ 457 / |C | | | \ 458 A v | ------- | v A 459 -------B | |E ------- 460 | FE1 |<-+ +->| FE2 | 461 | |<--------------->| | 462 ------- C D ------- 463 E ^ D| C ^ | B 464 | | | | 465 | v | v 466 FE3 Control Element reachability Table 467 -------------------------------------- 468 469 CE A 470 -------------------------------------- 472 FE3 NEIGHBOR ASSOCIATION TABLE 473 ----------------------------------------------- 474 475 B FE2 E 476 C FE1 B 477 ---------------------------------------------- 479 Figure 3. (a) Full mesh among FE1, FE2, and FE3 481 During the element-binding phase, each FE sends out hello messages 482 with its FEID and Port ID (as outlined earlier) to all of its 483 neighbors. Since each neighboring FE also listens to such messages, 484 it receives the hello message and adds it to the neighbor 485 association table, which may look like that shown in Fig.4(a). In 486 the topology discovery phase, which is post ForCES association 487 stage, the CE queries each FE about its neighbor table. The FE 488 responds back with the partial topology information available 489 through its neighbor relationships. Both the query and the response 490 are carried by the ForCES protocol. The CE collects the partial 491 topology information from all the FEs in the NE and aggregates this 492 information to fully construct the inter-FE topology. Any changes to 493 the FE neighbor table, e.g. when a link state changes, generates a 494 trigger/update message to the CE. The new information is used to 495 recalculate the new topology and subsequently the CE takes 496 appropriate actions based on the new topology � such as updating the 497 packet forwarding tables on the FEs. 499 The following examples show the neighbor association tables. 501 3.4.1. Forwarding Elements connected in a daisy chain 503 -------------- 504 | CE | 505 -------------- 506 A ^ ^ B ^ ^ D 507 / | \ \ 508 /------ | --\ -------\ 509 A v A v v A v A 511 -------B -------B -------B ------- 512 | FE1 |<--->| FE2 |<--->| FE3 |<--->| FE4 | 513 ------- E------- E------- D------- 514 D ^ |C D ^ |C D^ |C C^ |B 515 | | | | | | | | 516 | v | v | v | v 518 FE1 NBR ASSOCIATION TABLE FE2 NBR ASSOCIATION TABLE 519 -------------------------------- ------------------------------ 520 521 B FE2 E E FE1 B 522 B FE3 E 524 FE3 NBR ASSOCIATION TABLE FE4 NBR ASSOCIATION TABLE 525 -------------------------------- ----------------------------- 526 527 B FE4 D D FE3 B 528 E FE2 B 530 CE Topology (Aggregate)View CE Topology View 531 -------------------------------- ------------------------------ 532 533 FE1 B FE2 E\ FE1 B FE2 E 534 FE2 E FE1 B/ => FE2 B FE3 E 535 FE2 B FE3 E\ FE3 B FE4 D 536 FE3 E FE2 B/ ------------------------------ 537 FE3 B FE4 D\ 538 FE4 D FE3 B/ 539 -------------------------------- 541 Fig.3(b) Multiple FEs in a daisy chain 543 3.4.2. Forwarding Elements connected in a ring 545 ^ | 546 D| v E 547 ----------- A 548 | FE1 |<-----------------------| 549 ----------- | 550 C ^ ^ B | 551 / \ | 552 | ^ / \ ^ | V A 553 B v |C v D C v D| v E ---------- 554 --------- --------- D| | 555 | FE2 | | FE3 |<------------>| CE | 556 --------- --------- A | | 557 A ^ ^ E ^ B ---------- 558 | \ / C ^ ^ B 559 | \ / | | 560 | D v E v | | 561 | ----------- A | | 562 | | FE4 |<----------------------| | 563 | ----------- | 564 | C | ^ B | 565 | v | | 566 | | 567 |----------------------------------------| 569 FE1 NBR ASSOCIATION TABLE FE2 NBR ASSOCIATION TABLE 570 -------------------------------- ----------------------------- 571 572 B FE3 C E FE4 D 573 C FE2 D D FE1 C 575 FE3 NBR ASSOCIATION TABLE FE4 NBR ASSOCIATION TABLE 576 -------------------------------- ----------------------------- 577 578 B FE4 E D FE2 E 579 C FE1 B E FE3 B 581 Fig. 3(c) Multiple FEs connected in a ring 583 4. Security Considerations 585 Like all protocols, this protocol will have security issues as well. 586 These issues will be researched in detail in future draft versions. 588 5. References 590 5.1. Normative 592 [RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal, 593 "Forwarding and Control Element Separation (ForCES) 594 Framework", RFC 3746, April 2004. 595 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for 596 Separation of IP Control and Forwarding", RFC 3654, 597 November 2003. 598 [ForCESP] F P Team, "ForCES protocol specification", 599 draft-ietf-forces-protocol-00.txt, Sept 2004. 601 5.2. Informative 603 [OSPF] J. Moy, �OSPF Version 2�, 1998, RFC 2328. 604 [BGP] Y. Rekhter, T. Li, �A Border Gateway Protocol 4 (BGP-4)�, 605 1995, RFC 1771. 606 [IS-IS] R. Collela et al., �Guidelines for OSI NSAP Allocation in 607 the Internet�, 1994, RFC 1629. 609 6. Authors' Addresses 611 Furquan Ansari 612 Bell Labs Research, Lucent Tech. 613 101 Crawfords Corner Road 614 Holmdel, NJ 07733 615 USA 616 Phone: +1 732-949-5249 617 Email: furquan@lucent.com 619 Hormuzd Khosravi 620 Intel 621 2111 N.E. 25th Avenue JF3-206 622 Hillsboro, OR 97124-5961 623 USA 624 Phone: +1 503 264 0334 625 Email: hormuzd.m.khosravi@intel.com 627 Jamal Hadi Salim 628 ZNYX Networks 629 Ottawa, Ontario, Canada 630 Email: hadi@znyx.com 632 7. Full Copyright Notice 633 "Copyright (C) The Internet Society (year). This document is subject 634 to the rights, licenses and restrictions contained in BCP 78, and 635 except as set forth therein, the authors retain all their rights." 637 "This document and the information contained herein are provided on 638 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 639 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 640 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 641 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 642 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 645 8. Acknowledgements 646 We would like to thank Thyaga Nandagopal of Lucent Technologies for 647 his thoughts and contributions to the initial draft. 649 Funding for the RFC Editor function is currently provided by the 650 Internet Society.