idnits 2.17.1 draft-ietf-forces-discovery-02.txt: 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 3978, Section 5.1 on line 23. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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. == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 67 has weird spacing: '...3. Full topol...' == Line 222 has weird spacing: '...ors. No data...' == Line 228 has weird spacing: '... all the F...' == Line 368 has weird spacing: '...opology info...' == Line 413 has weird spacing: '...section on g...' == (6 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 (March 6, 2006) is 6619 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 3746' is mentioned on line 104, but not defined == Unused Reference: 'RFC3746' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'OSPF' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'BGP' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'IS-IS' is defined on line 688, 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-05 -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) Summary: 10 errors (**), 0 flaws (~~), 17 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Furquan Ansari 2 Internet Draft Lucent Tech. 3 Document: draft-ietf-forces-discovery-02.txt Hormuzd Khosravi 4 Expires: September 5, 2006 Intel Corp. 5 Working Group: ForCES Jamal Hadi Salim 6 Znyx Networks 7 Joel M. Halpern 8 Megisto Systems 9 Xiaoyi Guo 10 Huawei Tech. 11 March 6, 2006 13 ForCES Intra-NE Topology Discovery 15 draft-ietf-forces-discovery-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that 20 any applicable patent or other IPR claims of which he or she is 21 aware have been or will be disclosed, and any of which he or she 22 becomes aware will be disclosed, in accordance with Section 6 of 23 BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on September 5, 2006. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC-2119. 48 Abstract 50 This document describes a mechanism for discovering inter-FE topology, 51 topology maintenance in Intra-NE. Such a mechanism is essential for 52 all these elements in the set to behave as a single Network Element, 53 as required by the ForCES architecture as well as to perform certain 54 optimizations at the FE by making use of the topology. The mechanism 55 only operates during post-association phase of ForCES protocol. 57 Table of Contents 59 1. Definitions.........................................................2 60 2. Introduction........................................................3 61 2.1. Motivation....................................................4 62 3. Topology Discovery Mechanism........................................5 63 3.1. Minimum requirements..........................................6 64 3.2. Protocol Details..............................................6 65 3.2.1. Neighbor Finite State Machine............................8 66 3.2.2. Topology Discovery and Maintenance.......................8 67 3.2.3. Full topology computation at the CE from partial 68 topologies......................................................9 69 3.2.4. Update and Maintenance...................................9 70 3.3. Protocol and Message Headers.................................10 71 3.3.1. TLV definitions.........................................11 72 3.4. Inter-FE Topology Discovery Examples.........................12 73 3.4.1. Forwarding Elements connected in a daisy chain..........13 74 3.4.2. Forwarding Elements connected in a ring.................14 75 4. Security Considerations............................................15 76 5. References.........................................................15 77 5.1. Normative.....................................................15 78 5.2. Informative...................................................15 79 6. Authors' Addresses.................................................16 80 7. IANA Considerations................................................16 81 8. Full Copyright Notice..............................................17 82 9.Acknowledgements....................................................17 84 1. Definitions 86 Inter-FE topology discovery: Topology discovery relates to how the 87 FEs are interconnected with each other with respect to packet 88 forwarding. This is the complete view of the intra-NE network as 89 seen by the CE. 91 Inter-FE topology maintenance: Once the inter-FE topology has been 92 discovered, it has to be continuously monitored to ensure that any 93 changes to the topology are reported to the corresponding CE. This 94 represents the steady state and final phase of the protocol. 96 Edge FE: edge FE which has a port connected to other NEs or routers 97 outside of this NE, and also connects to intra-NE FE port. 99 Intra-NE: It describes the connection and status in a NE, these 100 status do not contact with outside NEs or other routers. 102 2. Introduction 104 The ForCES framework document [RFC 3746] describes how a set of 105 control elements (CEs) and forwarding elements (FEs) interact with 106 each other to form a single network element (NE). It describes the 107 ForCES post-association phase protocol working across the Fp 108 reference point between CE and FE. This document describes an 109 important aspect of the ForCES operational infrastructure - that of 110 discovering the layout of the different elements and forwarding 111 packet within an NE. 113 The Inter-FE/Intra-NE topology discovery protocol module may be 114 implemented as some separate LFBs on the FE. The protocol runs in an 115 ongoing discovery and maintenance mode wherein the LFB maintains 116 information about the known adjacencies per interface it is operated 117 on. Each FE simply maintains its own adjacency tables and notifies 118 the CE of any changes to the adjacency table based on the ForCES 119 notification mechanism or if the CE explicitly requests an update. 120 It is up to the CE to construct the full topology based on the 121 information received from individual FEs within the NE and generate 122 the NE routing table. Given that the CE can request and the FEs 123 should report back the topology updates using ForCES protocol. 125 The proposed discovery mechanism is required to scale to a very 126 large number of forwarding elements in the NE, with minimal impact 127 on the resources. The following list provides some of the features 128 and goals of the discovery mechanism. 130 . Determine connectivity between elements 131 . React to changes in link connectivity 132 . Construct topology information from the collected partial 133 topology information 134 . Tolerant to protocol message losses 135 . Applicable to all inter-FE network topologies such as ring, mesh, 136 star etc. 137 . Cause minimal overhead 138 . Agnostic of the network interconnect technology 140 As noted above, it is implicit that all the phases occur in the 141 ForCES post-association phase. In other words, the ForCES protocol 142 association between the CEs and the FEs should already have taken 143 place. 145 2.1. Motivation 147 The ForCES architecture defines a network element (NE) as a single 148 managed entity made up of a collection of FEs and CEs and is 149 indistinguishable from other network elements in the network. This NE 150 model definition leads to three types of links from the network 151 perspective: internal (or intra-NE) links and external (or inter-NE) 152 links and control links. Intra-NE links are purely internal to the 153 NE and are not exposed to the external world; whereas, inter-NE (or 154 external) links are exposed to the external world and over which 155 routing adjacencies (such as OSPF, IS-IS, BGP etc.) can be formed. 156 An NE can contain FEs that have zero or more internal/external links 157 e.g. in Fig. 1, FE3 has two internal links and no external links 158 while FE1 and FE2 have two internal links and one external link 159 each. Control links are those links that are used for communication 160 between the CE and FE. If the CE and FE are a single Layer 3 hop 161 apart as in Fig.1, the control link is typically a physical link 162 e.g. link A of FE1 in the figure. Control links can be logical as 163 well. It is important to note that the type definition for given for 164 a link is only logical, because a given physical link may be a 165 combination of more than one type - e.g. it could simultaneously be 166 a control link and an internal link at the same time. Based on this 167 link definitions, an FE can be considered to be an internal FE if it 168 only contains internal links and an edge FE if it contains external 169 links (and may also contain internal links). 171 A packet entering a ForCES NE may travel multiple FEs within the NE 172 before it exits onto the output link. This requires that the packet 173 be correctly forwarded from the ingress FE to the egress FE. This 174 internal forwarding requires knowledge of the physical FE inter- 175 connection topology so that the CE can appropriately setup internal 176 LFB tables at each FE to handle packet traversal in a sane manner. 178 NE 1 179 ..................................... 180 . ----------------- . 181 . | CE | . 182 . ----------------- . ---------- 183 . A ^ B ^ C ^ . | NE 1 | 184 . / | \ . | | 185 . / A v \ . ---------- 186 . / ------- B \ . ^ ^ 187 . / +->| FE3 |<-+ \ . <====> / \ 188 . / |C | | | \ . / \ 189 . A v | ------- | v A . v v 190 . -------B | |D ------- . -------- --------- 191 . | FE1 |<-+ +->| FE2 | . | NE 2 |<---->| NE 3 | 192 . | |<--------------->| | . | | | | 193 . ------- C C ------- . -------- --------- 194 . D^ ^B . 195 .....|.......................|........ 196 | | 197 V V 198 -------- -------- 199 | NE 2 |<--------------->| NE 3 | 200 | | | | 201 -------- -------- 202 (a) (b) 204 Figure 1:(a) illustrates the internal/external links and topology 205 within a NE. (b) Shows the network topology as seen by external 207 routing protocols 209 3. Topology Discovery Mechanism 211 Since the topology discovery protocol described here operates in the 212 ForCES post-association phase, it is independent of whether the CE 213 and the FE is a single or multiple hops (layer 2 or layer 3) apart 214 from each other. It is up to the ForCES association protocol to 215 determine how to setup the ForCES channel between the CE and FE if 216 they are multiple hops away. The topology discovery protocol is 217 expected to work on all types of media and interfaces such as point- 218 to-point as well as multi-access links. 220 In order to keep the discovery and maintenance mechanism as simple as 221 possible, the FEs only maintain relationships with their respective 222 neighbors to determine the status of the neighbors. No databases 223 are exchanged between the neighbors. This implies that the 224 topology view for each FE is only limited to the adjacent elements. 225 This partial topology information may be reported back to the CE (or 226 queried by the CE) over the ForCES protocol using the ForCES 227 notification mechanism. Since the CE receives such information from 228 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). The FEs may use such 232 information for dynamic intra-NE route calculation or certain other 233 optimizations. 235 Topology information is needed by a lot of LFBs and associated 236 services that span multiple FEs within a NE. In the case where the 237 FE aids the CE in offloading the table updates, then it makes sense 238 for the FE to be topology aware. It is sometimes also helpful to 239 keep full topology information at the FEs for cases such as message 240 snooping optimizations. For example, if an FE is aware of the 241 topology, it could snoop on messages sent to other FEs (e.g., 242 broadcasts, multicasts) and update its own tables dynamically 243 without involving the CE. Another example would be FE-FE primary- 244 backup handover scenario. With each FE being fully aware of the 245 complete topology, the backup FE can take over the responsibilities 246 of the primary without involving the CE for such a handover. 248 3.1 Minimum requirements 250 In order for the protocol to work as described, the following 251 assumptions are made. 253 . Each element has been configured with their respective IDs 254 (CEID, FEID) 256 . Element bindings process has already taken place. In other 257 words, the CE know all the FEs it wants to control and each FE 258 knows which CE is allowed to control it. 260 . The ForCES protocol association has already taken place between 261 the CE and the FE in question. 263 . The protocol is enabled on the required interfaces. 265 Note that these are configuration requirements and are satisfied by 266 the respective managers (CEM/FEM). 268 3.2 Protocol Details 270 Once the ForCES protocol association has been established between a 271 CE and a given FE i.e. it is in post-association phase, the CE 272 starts sending/advertising Hello/Probe messages to the FE 273 neighbors such that the messages go through the given FE. In other 274 words, it looks like the given FE is generating probe messages to 275 the neighbor (except that these messages are coming from the CE over 276 the ForCES protocol first). However, this functionality of 277 generating probe messages by the CE can be offloaded to the FE 278 itself (to be more precise, to an FE LFB) so that the FE can 279 originate and terminate the probe messages. This provides better 280 scalability of the CE and it resources. The CE can now simply query 281 each FE neighbor relationship database and register for any events 282 related to topology changes. 284 All Hello/Probe messages travel a single PE hop and are not routed 285 to other elements beyond the first hop. An on-link IP multicast 286 address is used for sending all Hello packets. The packets should be 287 sent with a TTL of 255 and ignored on receipt if the TTL is not 254 288 (based on some of the recommendations from the generalized TTL 289 security mechanism to use TTL 255 rather than TTL 1). Hello packets 290 are only sent on interfaces configured for topology discovery 291 protocol operation. Further, the Hello messages will be multicast on 292 multicast capable links. Each FE topology LFB component maintains 293 the neighbor relationships as long as the Hello messages are 294 received from the neighbor. If it does not receive Hello messages 295 after a given (configured) period of time (called FE Neighbor dead 296 interval), it deletes the entry from the database and reports this 297 change to the CE in the form of an event-notification message over 298 the ForCES protocol. This ensures that the CE has the complete and 299 up-to-date information of the underlying topology of the Inter-FE 300 network. 302 The Hello message contains information necessary for discovering and 303 maintaining neighbor relationships. It contains the PE ID, type of 304 protocol element (i.e. CE or FE), interval between any two messages, 305 interval for deeming a neighbor inactive, capability information etc. 306 This is, in some ways, similar to the capabilities of the OSPF Hello 307 protocol. 309 On receiving the Hello messages from a neighbor, the FE responds back 310 with its own Hello message in a packet format similar to the one 311 received from the neighbor. Essentially, both sides are 312 independently sending Hello messages to each other and listing their 313 neighbor table. Also, each neighbor will see itself listed on its 314 neighbors Hello message. This ensures bi-directionality of the link 315 between any two neighbors. 317 The operation is concisely described by the following steps: 319 . CE activates the topology LFB/component on the FE to initialize on 320 specific ports 322 . FE topology LFB/component sends neighbor probes/hellos 324 . CE queries FE for its neighbors 326 . FE continues to send these probes afterwards (maintenance) and 327 updates asynchronously any new updates 329 Note: We would like to point out here that the Hello messaging 330 mechanism can very well be replaced by the BFD (Bi-Directional 331 Forwarding Detection) protocol in the future since it performs 332 similar task of detecting bi-directional faults between two 333 forwarding engines. Further, BFD protocol has the ability to be 334 bootstrapped by any other protocol that automatically forms peer, 335 neighbor or adjacency relationships to seed BFD endpoint discovery. 337 3.2.1. Neighbor Finite State Machine 339 In order to obtain bi-directionality verification of the links, and 340 to make the protocol more robust, a neighbor finite state machine is 341 needed. It consists of the following three states: 343 Neighbor-down: This is the initial state of the neighbor 344 conversation. It indicates that there has been no recent information 345 received from the neighbor 347 Neighbor-heard: In this state, a Hello packet was recently seen from 348 the neighbor. However, bi-directional communication has not been 349 fully established with the neighbor (i.e. the PE itself was not 350 listed in the neighbor Hello packet which is the check for bi- 351 directionality). All neighbors in this state (or higher) are listed 352 in the Hello packets sent from the associated interface. 354 Neighbor-adjacent: In this state, the communication between the two 355 neighbors is bi-directional. This has been assured by the Hello 356 protocol operation. This state corresponds to the final steady state 357 of the protocol. 359 3.2.2. Topology Discovery and Maintenance 361 Since the CE needs to maintain consistent and up-to-date view of the 362 inter-FE topology, it needs to obtain real-time information of the 363 status of the internal links connecting the FEs. Since the topology 364 discovery and maintenance occurs during the post-association phase, 365 we make use of the event-notification and query/response messages 366 [ForCESP] of the ForCES protocol to provide this information to the 367 CE. It is important to note that each FE only maintains partial 368 topology information obtained through neighbor relationship 369 maintenance through Hello messages. The partial topology view seen 370 by each FE is only the neighbor connectivity information. The CE has 371 to derive the complete topology view of the interconnected FEs based 372 on the partial topology information reported by each FE (or queried 373 by the CE). This ensures that that only the CE maintains all the 374 intelligence and the protocol operation on the FEs is very simple 375 and has minimal overhead. However, as mentioned above, if 376 optimizations can be performed by having the complete topology 377 information available at the FEs, the CE can push such information 378 to any FE interested in it (interest on the FE may be shown in the 379 form of policy configuration). This is an optional feature available 380 on each FE, which can be turned on or off through configuration or 381 during capability exchange negotiation at setup time. Each FE vendor 382 may decide to make use of this feature in different ways, so the 383 capability to obtain such topology information should exist. 385 The periodic Hello messages maintain PE neighbor relationships. 386 Any change in the link or neighbor status causes the FE to generate 387 an asynchronous/event-driven message to the CE indicating this 388 change. The mechanism defined in [ForCESP] is used for delivering 389 event-driven messages from the FE to the CE. This involves the CE 390 subscribing to such event-driven messages from the FE. 392 3.2.3. Full topology computation at the CE from partial topologies 394 The CE receives neighbor relationships information from each FE that 395 it uses to construct the full topology of the internal network. Each 396 FE neighbor relationship table contains information regarding the 397 local element ID, local port connecting the neighbor, the neighbor 398 ID, the neighbor port and any optional additional information. 399 Note that the fact that the FE already knows the neighbor port 400 information implies that it received the probe/hello messages from 401 the neighbor on that port in response to the hello sent and was, 402 therefore, able to establish bi-directionality of the link. If all 403 the links in the internal network are point-to-point links, the CE 404 simply has to aggregate all the neighbor relationship tables 405 obtained from all the FEs to generate the full topology. If we 406 assume the topology to be a graph, each edge of the graph will be 407 present twice essentially providing the same information from the 408 two endpoints of the graph. After deleting all the duplicate entries 409 (and thus reducing the table size by half), the CE now has accurate 410 view of the full topology. Please refer section 3.4 [Fig. 3(b)] for 411 more details. 413 [TBD: Sub-section on generating full topology from partial 414 topology information for broadcast/multi-access, point-to- 415 multipoint etc. type of links] 417 3.2.4. Update and Maintenance 419 The periodic Hello messages maintain PE neighbor relationships. Any 420 change in the link or neighbor status causes the FE to generate an 421 asynchronous/event-driven message to the CE indicating this change. 422 The mechanism defined in [ForCESP] is used for delivering event- 423 driven messages from the FE to the CE. This involves the CE 424 subscribing to such event-driven messages from the FE. 426 The CE aggregates the partial topology information received from 427 each FE and generates the inter-FE topology. With this complete 428 knowledge of the inter-FE topology, it can now make appropriate 429 updates to the LFB tables and routing table on each FE to move 430 packets inside the NE from ingress FE to egress FE, assuming that 431 the destination of the packet is not the current NE itself. Any 432 changes in the internal link states (and hence the topology) 433 requires that the CE reconfigure the LFB tables on the FEs based 434 on the most up-to-date information to ensure that the packets do not 435 end up in a black hole or enter a loop. 437 3.3. Protocol and Message Headers 439 The protocol hello message consists of a fixed length header (16 440 bytes) followed by one or more optional TLVs. The format of the 441 message is as follows. 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Version | Flags | Packet Length | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Checksum | Port ID | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | PE ID | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | TLV-Type | TLV-Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | TLV-Value ... | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | ... | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure (2) 461 Version (8 bit): 462 Version number of this protocol. Currently acceptable value 463 is 0x01 465 Flags (8 bit): 466 These indicate whether the message is sent by a FE, (0x01) or 467 CE (0x02). More options may be defined in the future. 469 Packet Length (16 bit): 470 The length of the protocol message in bytes, including the 471 header and the following TLVs. 473 Checksum (16 bit): 474 Checksum for the protocol message. The checksum calculation 475 does not include the IP header. 477 Port ID (16 bit): 478 This indicates the port on which this packet was sent out by 479 the sender useful for topology construction. 481 PE ID (32 bit): 482 32-bit identifier of the sender. It could either be CE ID or 483 FE ID, depending on the sender. See more details in ForCES 484 protocol section 6.1. 486 TLV Type (16 bit): 487 The TLV type field is two octets, and indicates the 488 type of data encapsulated within the TLV. 490 TLV Length (16 bit): 491 The TLV Length field is two octets, and indicates 492 the length of this TLV including the TLV Type, TLV Length, 493 and the TLV data in octets. 495 TLV Value (variable): 496 The TLV Value field carries the data. For extensibility, 497 the TLV value may in fact be a TLV. TLVs must be 32 bit 498 aligned. Padding used for the alignment must be zero on 499 transmission and must be ignored upon reception. 501 3.3.1. TLV definitions 503 The protocol header is followed by one or many TLVs. The following 504 TLVs types are defined: 506 Hello TLV: Indicates the Hello message as exchanged by the neighbors. 507 The TLV defines the common hello parameters such as the 508 Hello Interval, Hold time, Unidirectional targeted Hellos, 509 Sequence space number, if needed etc. 511 Data TLV: Indicates the neighbor or the topology information from 512 CE or neighbor FE. 514 Capabilities TLV: Provides the capabilities information - TBD 516 Vendor specific TLV: TBD 518 Other TLV: TBD 520 3.4. Inter-FE Topology Discovery Examples 521 The following examples illustrate the topology discovery mechanism. 522 For sake of simplicity, we assume that there is only one CE per NE. 523 The FEIDs of the FEs in the topologies below are FE1, FE2, FE3, and 524 FE4. Each FE has port IDs labeled alphabetically. This is also the 525 case with the CE. 527 ----------------- 528 | CE | 529 ----------------- 530 A ^ B ^ C ^ 531 / | \ 532 / A v \ 533 / ------- B \ 534 / +->| FE3 |<-+ \ 535 / |C | | | \ 536 A v 2| ------- |1 v A 537 -------B | |E ------- 538 | FE1 |<-+ +->| FE2 | 539 | |<--------------->| | 540 ------- C 5 D ------- 541 E ^ D| C ^ | B 542 | | | | 543 | v | v 545 FE3 Control Element reachability Table 546 -------------------------------------- 547 548 CE A 549 -------------------------------------- 551 FE3 NEIGHBOR ASSOCIATION TABLE 552 ----------------------------------------------- 553 554 B FE2 E 555 C FE1 B 556 ----------------------------------------------- 557 Figure 4. (a) Full mesh among FE1, FE2, and FE3 559 During the element-binding phase, each FE sends out hello messages 560 with its FEID and Port ID (as outlined earlier) to all of its 561 neighbors. Since each neighboring FE also listens to such messages, 562 it receives the hello message and adds it to the neighbor 563 association table, which may look like that shown in Fig.4(a). In 564 the topology discovery phase, which is post ForCES association stage, 565 the CE queries each FE about its neighbor table. The FE responds 566 back with the partial topology information available through its 567 neighbor relationships. Both the query and the response are carried 568 by the ForCES protocol. The CE collects the partial topology 569 information from all the FEs in the NE and aggregates this 570 information to fully construct the inter-FE topology. Any changes to 571 the FE neighbor table, e.g. when a link state changes, generates a 572 trigger/update message to the CE. The new information is used to 573 recalculate the new topology and subsequently the CE takes 574 appropriate actions based on the new topology such as updating the 575 packet forwarding tables on the FEs. 577 The following examples show the neighbor association tables. 579 3.4.1. Forwarding Elements connected in a daisy chain 581 -------------- 582 | CE | 583 -------------- 584 A ^ ^ B ^ ^ D 585 / | \ \ 586 /------ | --\ -------\ 587 A v A v v A v A 588 -------B -------B -------B ------- 589 | FE1 |<--->| FE2 |<--->| FE3 |<--->| FE4 | 590 ------- E------- E------- D------- 591 D ^ |C D ^ |C D^ |C C^ |B 592 | | | | | | | | 593 | v | v | v | v 595 FE1 NBR ASSOCIATION TABLE FE2 NBR ASSOCIATION TABLE 596 -------------------------------- ------------------------------ 597 598 B FE2 E E FE1 B 599 B FE3 E 601 FE3 NBR ASSOCIATION TABLE FE4 NBR ASSOCIATION TABLE 602 -------------------------------- ----------------------------- 603 604 B FE4 D D FE3 B 605 E FE2 B 607 CE Topology (Aggregate)View CE Topology View 608 -------------------------------- ------------------------------ 609 610 FE1 B FE2 E\ FE1 B FE2 E 611 FE2 E FE1 B/ => FE2 B FE3 E 612 FE2 B FE3 E\ FE3 B FE4 D 613 FE3 E FE2 B/ ------------------------------ 614 FE3 B FE4 D\ 615 FE4 D FE3 B/ 616 -------------------------------- 618 Fig.4 (b) Multiple FEs in a daisy chain 620 3.4.2. Forwarding Elements connected in a ring 622 ^ | 623 D| v E 624 ----------- A 625 | FE1 |<-----------------------| 626 ----------- | 627 C ^ ^ B | 628 / \ | 629 | ^ / \ ^ | V A 630 B v |C v D C v D| v E ---------- 631 --------- --------- D| | 632 | FE2 | | FE3 |<------------>| CE | 633 --------- --------- A | | 634 A ^ ^ E ^ B ---------- 635 | \ / C ^ ^ B 636 | \ / | | 637 | D v E v | | 638 | ----------- A | | 639 | | FE4 |<----------------------| | 640 | ----------- | 641 | C | ^ B | 642 | v | | 643 | | 644 |----------------------------------------| 646 FE1 NBR ASSOCIATION TABLE FE2 NBR ASSOCIATION TABLE 647 ------------------------------- ----------------------------- 648 649 B FE3 C E FE4 D 650 C FE2 D D FE1 C 652 FE3 NBR ASSOCIATION TABLE FE4 NBR ASSOCIATION TABLE 653 -------------------------------- ----------------------------- 654 655 B FE4 E D FE2 E 656 C FE1 B E FE3 B 658 Fig. 4(c) Multiple FEs connected in a ring 660 4. Security Considerations 662 The ForCES protocol should ensure the communication security between 663 CEs and FEs. FEs should ensure that only properly authenticated ForCES 664 protocol participants are performing such manipulations. 666 5. References 668 5.1 Normative 670 [RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal, 671 "Forwarding and Control Element Separation (ForCES) 672 Framework", RFC 3746, April 2004. 674 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 675 of IP Control and Forwarding", RFC 3654, 676 November 2003. 678 [ForCESP] F P Team, "ForCES protocol specification", 679 draft-ietf-forces-protocol-05.txt, Nov 2006. 681 5.2 Informative 683 [OSPF] J. Moy, OSPF Version 2, 1998, RFC 2328. 685 [BGP] Y. Rekhter, T. Li, Border Gateway Protocol 4 (BGP-4) 686 1995, RFC 1771. 688 [IS-IS] R. Collela et al., guidelines for OSI NSAP Allocation in 689 the Internet 1994, RFC 1629. 691 6. Authors' Addresses 693 Furquan Ansari 694 Bell Labs Research, Lucent Tech. 695 101 Crawfords Corner Road 696 Holmdel, NJ 07733 697 USA 698 Phone: +1 732-949-5249 699 Email: furquan@lucent.com 701 Hormuzd Khosravi 702 Intel 703 2111 N.E. 25th Avenue JF3-206 704 Hillsboro, OR 97124-5961 705 USA 706 Phone: +1 503 264 0334 707 Email: hormuzd.m.khosravi@intel.com 709 Jamal Hadi Salim 710 ZNYX Networks 711 Ottawa, Ontario, Canada 712 Email: hadi@znyx.com 714 Joel M. Halpern 715 Megisto systems, Inc. 716 0251 Century Blvd. 717 Germantown, MD, 20874-1162, USA 718 Phone: +1 301 444 17 719 Email: jhalpern@megisto.com 721 Xiaoyi Guo 722 Huawei Tech. 723 No.3 Xinxi Rd., Shang-Di, 724 Hai-Dian District Beijing P.R. China 726 7. IANA Considerations 728 There are no IANA considerations at this point since the protocol 729 completely operates within an NE. 731 8. Full Copyright Notice 733 "Copyright (C) The Internet Society (2006). This document is subject 734 to the rights, licenses and restrictions contained in BCP 78, and 735 except as set forth therein, the authors retain all their rights." 737 "This document and the information contained herein are provided on 738 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 739 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 740 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 741 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 742 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 743 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 745 9. Acknowledgments 747 We would like to thank Thyaga Nandagopal of Lucent Technologies for 748 his thoughts and contributions to the initial draft. 750 Funding for the RFC Editor function is currently provided by the 751 Internet Society.