idnits 2.17.1 draft-rfced-info-nagami-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 112 has weird spacing: '...regated flow...' == Line 294 has weird spacing: '...sage is the s...' == Line 303 has weird spacing: '...egister the m...' == Line 657 has weird spacing: '...version numb...' == Line 661 has weird spacing: '...s field indic...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1997) is 9931 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'VCID' on line 529 ** Obsolete normative reference: RFC 1577 (ref. '2') (Obsoleted by RFC 2225) ** Obsolete normative reference: RFC 1483 (ref. '3') (Obsoleted by RFC 2684) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft K. Nagami 3 Expires: July 1997 Y. Katsube 4 Category: Informational Y. Shobatake 5 A. Mogi 6 S. Matsuzawa 7 T. Jinmei 8 H. Esaki 9 Toshiba R&D Center 10 February 1997 12 Flow Attribute Notification Protocol (FANP) Specification 13 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 This memo discusses Flow Attribute Notification Protocol (FANP), 36 which is a protocol between neighbor nodes for the management of 37 cut-through packet forwarding functionalities. In cut-through packet 38 forwarding, a router doesn't have to perform conventional IP packet 39 processing for received packets. FANP indicates mapping information 40 between a datalink connection and a packet flow to the neighbor node 41 and helps a pair of nodes manage the mapping information. By using 42 FANP, routers (e.g., CSR; Cell Switch Router) can forward incoming 43 packets based on their datalink-level connection identifiers, 44 bypassing usual IP packet processing. The design policy of the FANP 45 is; 47 (1) soft-state cut-through path (Dedicated-VC) management 48 (2) protocol between neighbor nodes instead of end-to-end 49 (3) applicable to any connection oriented datalink platform 51 1. Background 53 Due to the scalability requirement, connection oriented (CO) datalink 54 platforms, e.g., ATM and Frame Relay, are going to be used as well as 55 connection less (CL) datalink platforms, e.g., Ethernet and FDDI. 56 One of the important features of the CO datalink is the presence of a 57 datalink-level connection identifier. In the CO datalink, we can 58 establish multiple virtual connections (VCs) with their VC 59 identifiers among the nodes. When we aggregate packets that have the 60 same direction (e.g., having the same destination IP address) into a 61 single VC, we can forward the packets in the VC without IP 62 processing. With this configuration, routers can decide which node 63 is the next-hop for the packets based on the VC identifier. CSRs [1] 64 can forward the incoming packets using an ATM switch engine bypassing 65 the conventional IP processing. According to the ingress VPI/VCI 66 value with ingress interface information, CSR determines the egress 67 interface and egress VPI/VCI value. 69 In order to configure the cut-through packet forwarding state, a pair 70 of neighbor nodes have to share the mapping information between the 71 packet flow and the datalink VC. FANP (Flow Attribute Notification 72 Protocol) described in this memo is the protocol to configure and 73 manage the cut-through packet forwarding state. 75 2. Protocol Requirements and Future Enhancement 77 2.1 Protocol Requirements 79 The followings are the protocol requirements for FANP. 81 (1) Applicable to various types of CO datalink platforms 83 (2) Available with various connection types (i.e., SVC, PVC, VP) 85 (3) Robust operation 86 The system should operate correctly even under the following 87 conditions. 89 (a) VC failure 90 Some systems can detect VC failure as the function of 91 datalink (e.g., OAM function in the ATM). However, we can 92 not assume all nodes in the system can detect VC failure. 93 The system has to operate correctly, assuming that every 94 node can not detect VC failure. 96 (b) Message loss 97 Control messages in the FANP may be lost. The system has to 98 operate correctly, even when some control messages are lost. 100 (c) Node failure 101 A node may be down without any explicit notification to its 102 neighbors. The system has to operate correctly, even with 103 node failure. 105 Though FANP is not the protocol only for ATM, the following 106 discussion assumes that the datalink is an ATM network. 108 2.2 Future Enhancement 110 The followings are the future enhancements to be done. 112 (1) Aggregated flow 113 In this memo, we define the flow which contain source and 114 destination IP address. As this may require many VC 115 resources, we also need a new definition of aggregated flow 116 which includes several end-to-end flows. The concrete 117 definition of the aggregated flow is for future study. 119 (2) Providing multicast service 120 (3) Supporting IP level QOS signaling like RSVP 121 (4) Supporting IPv6 123 3. Terminology and Definition 125 o VCID (Virtual Connection IDentifier) 126 Since VPI/VCI values at the origination and the termination 127 points of a VC (and VP) may not be the same, we need an 128 identifier to uniquely identify the datalink connection between 129 neighbor nodes. We define this identifier as a VCID. 130 Currently, only one type of VCID is defined. This VCID contains 131 the ESI (End System Identifier) of a source node and the unique 132 identifier within a source node. 134 o Flow ID (Flow IDentifier) 135 IP level packet flow is identified by some parameters in a 136 packet. Currently, only one type of flow ID is defined. This 137 flow ID contains a source IP address and a destination IP 138 address. Note that flow ID used in this specification is not 139 the same as the flow-id specified in IPv6. 141 o Cut-through packet forwarding 142 Packets are forwarded without any IP processing at the router 143 using the datalink level information (e.g.,VPI/VCI). 145 Internetworking level information (e.g., destination IP address) 146 is mapped to the corresponding datalink-level identifier by 147 using the FANP. 149 o Hop-by-Hop packet forwarding 150 Packets are forwarded using IP level information like 151 conventional routers. In ATM, cells are re-assembled into 152 packets at the router to analyze the IP header. 154 o Default-VC 155 Default-VC is used for hop-by-hop packet forwarding. Cells 156 received from the Default-VC are reassembled into IP packets. 157 Conventional IP processing is performed for these packets. The 158 encapsulation over the Default-VC is LLC for routed non-ISO 159 protocols defined by RFC1483 [3]. 161 o Dedicated-VC 162 Dedicated-VC is used for the specific IP packet flow identified 163 by the flow-ID. When the flow-ID for an incoming VC and an 164 outgoing VC are the same at a CSR, it can forward the packets 165 belonging to the flow through the cut-through packet forwarding. 166 The encapsulation over the Dedicated-VC is LLC for routed 167 non-ISO protocols defined by RFC1483 [3]. 169 o Cut-through trigger 170 When a FANP capable node receives a trigger packet, it tries to 171 establish Dedicated-VC and to notify the mapping information 172 between the Dedicated-VC and the IP packet flow which the 173 received trigger packet belongs to. Trigger packets are defined 174 by the port-ID of TCP/UDP with the local policy of each FANP 175 capable node. In general, they would be the port-ID's of 176 sessions with a long life-time and/or with large amount of 177 packets; e.g., http, ftp and nntp. Future implementation will 178 include other triggers such as an arrival of resource 179 reservation request. 181 4. Protocol Overview 183 Figure 1 shows an operational overview of FANP. In the figure, a 184 cut-through packet forwarding path is established from host 1 (H1) to 185 host 2 (H2) using two Dedicated-VCs. H1 and H2 are connected to 186 Ethernets, and R1, R2 and R3 are routers which can speak FANP. R1 187 and R3 have both an ATM interface and an Ethernet interface. R2 has 188 two ATM interfaces. 190 When R1 receives an IP packet from H1, R1 analyzes the payload of the 191 received IP packet whether it is a trigger packet or not. When the 192 received packet is a trigger packet, R1 fetches a Dedicated-VC to its 193 downstream neighbor(R2) and sends FANP messages. FANP is effective 194 between the neighboring nodes only. The same procedure would be 195 performed between R2 and R3 independently from the procedure between 196 R1 and R2. The flow-ID of the packet flow from H1 to H2 is 197 represented as id(H1,H2). Here, id(H1,H2) is the set of the IP 198 address of H1 and that of H2. 200 The Dedicated-VC is released when no packet is transferred on it for 201 a given period. We do not need to explicitly indicate release of the 202 Dedicated-VC to the neighbor node, since the state management in FANP 203 is of soft-state, rather than of hard-state. 205 +--+ Ethernet +--+ +-----+ +--+ +-----+ +--+ Ethernet +--+ 206 |H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2| 207 +--+ +--+ +-----+ +--+ +-----+ +--+ +--+ 208 trigger pkt 209 |----------> trigger packet 210 |-------------> trigger packet 211 FANP |--------------> trigger pkt 212 <=============> FANP |-----------> 213 <==============> 215 |=============| 216 Dedicated-VC |==============| 217 Dedicated-VC 219 Figure 1. Trigger packet and FANP initiation 221 5. Protocol Sequence 223 FANP has the following five procedures, that are (1) Dedicated-VC 224 selection, (2) VCID negotiation, (3) flow-ID notification, (4) 225 Dedicated-VC refresh and (5) Dedicated-VC release. Procedures (2), 226 (3) and (4) have nothing to do with the kind of the Dedicated- 227 VC;i.e.,SVC,PVC or VP. On the contrary, the procedures (1) and (5) 228 with SVC are different from the procedures with PVC and with VP. 230 The detailed procedures are described in the following subsections. 232 5.1 Dedicated-VC Selection Procedure 234 A VC is picked up in order to use as a Dedicated-VC. The ways of 235 picking up the Dedicated-VC is either of the followings. 237 (1) A number of VCs are prepared in advance, and registered into an 238 un-used VC list. When a Dedicated-VC is needed, one of them is 239 picked up from the un-used VC list. 241 (2) A new VC is established through ATM signaling on demand. 243 With ATM PVC/VP configuration, a Dedicated-VC is activated by the 244 procedure (1). 246 With ATM SVC configuration, a Dedicated-VC is activated by the 247 procedure (1) or (2). When the procedure (1) is used, some number of 248 VCs are prepared in advance through ATM signaling. These VCs are 249 registered into the un-used VC list. When a Dedicated-VC is needed, 250 a VC is picked up from the un-used VC list. When the procedure (2) 251 is used, a Dedicated-VC is established through ATM signaling each 252 time it is required. 254 The procedure (1) can decrease a time to activate a Dedicated-VC. 255 But the necessary VC resource will increase as it need to prepare 256 additional VCs. Which procedure should be applied to is a matter of 257 local decision in each node, taking the economical requirement and 258 the system responsiveness into account. 260 A Dedicated-VC is used as a uni-directional VC, although it is 261 generally bi-directional. This means that packets are transferred 262 only from upstream node to downstream node in the Dedicated-VC. The 263 packets from downstream node to upstream node are transferred through 264 the Default-VC or through another Dedicated-VC. 266 5.2 VCID Negotiation Procedure 268 After the Dedicated-VC selection procedure, the upstream node 269 transmits the PROPOSE message to the downstream node through the 270 Dedicated-VC. The PROPOSE message contains a VCID for the 271 Dedicated-VC and IP address (target IP address) of downstream node. 272 When the downstream node accepts the PROPOSE message, it transmits 273 the PROPOSE ACK message to the upstream node through the Default-VC. 274 With this procedure, the upstream and the downstream nodes (both 275 end-points of the Dedicated-VC) can share the same indicator "VCID" 276 for the Dedicated-VC. When the downstream node can not accept the 277 proposal from the upstream node with some reason (e.g., policy), the 278 downstream node sends an ERROR message to the upstream node through 279 the Default-VC. 281 The procedure at the downstream node which has received PROPOSE 282 message is; 284 1. if(Target IP address of the PROPOSE message isn't equal to my IP 285 address) 286 then Goto end. 288 2. if(The PROPOSE message should be refused) 289 then Send an ERROR(refuse by policy) message. Go to end. 291 3. if(VCID Type in the PROPOSE message isn't known) 292 then Send an ERROR(unknown VCID Type) message. Go to end. 294 4. if(The VCID in the PROPOSE message is the same as the VCID which 295 has already been registered for another Dedicated-VC in the node) 296 then Delete the registered VCID. 297 Release the old Dedicated-VC. 299 5. if(A VCID is registered for the Dedicated-VC which has received 300 the PROPOSE message) 301 then Delete the registered VCID. 303 6. Register the mapping between VCID and I/F, VPI, VCI for the 304 Dedicated-VC. 306 7. if(The mapping is successful) 307 then Send a PROPOSE ACK. 308 else Send an ERROR(resource unavailable). 310 The upstream node retransmits the PROPOSE message when it neither 311 receive PROPOSE ACK message nor ERROR message. When the upstream 312 node has received neither of the messages even with five 313 retransmissions of the PROPOSE message, the Dedicated-VC picked up 314 through the Dedicated-VC selection procedure should be released. 315 Here, the number of retransmissions (five in this specification)is 316 recommended value and can be modified in the future. 318 The purpose of the VCID negotiation procedure is not only to share 319 the VCID information regarding the Dedicated-VC, but also to confirm 320 whether the Dedicated-VC is available and whether the neighbor node 321 operates correctly. 323 If the VCID negotiation procedure with a neighbor node always fails, 324 it is considered that the node may not be FANP-capable node. 325 Therefore the upstream node should not try the VCID negotiation 326 procedure to that node for a certain time period. 328 5.3 Flow-ID Notification Procedure 330 After the VCID negotiation procedure, the upstream node transmits an 331 OFFER message to the downstream node through the Default-VC. The 332 OFFER message contains the VCID of the Dedicated-VC, the flow-ID of 333 the packet flow transferred through the Dedicated-VC and the refresh 334 interval of a READY message. 336 When the downstream node receives the OFFER message from the upstream 337 node, it transmits the READY message to the upstream node through the 338 Default-VC in order to indicate that the OFFER message issued by the 339 upstream node is accepted. By the reception of the READY message, 340 the upstream node realizes that the downstream node can receive IP 341 packets transferred through the Dedicated-VC. 343 The upstream node retransmits the OFFER message when it does not 344 receive a READY message from the downstream node. When the upstream 345 node has not receive a READY message even with five retransmissions, 346 the Dedicated-VC should be released. Here, the number of 347 retransmissions (i.e., five in this specification) is a recommended 348 value and may be modified in the future. 350 The node transmits an ERROR message to its neighbor in the following 351 cases. When the node receives the ERROR message, the Dedicated-VC 352 should be released. 354 (a) unknown VCID: The VCID in the message is unknown. 355 (b) unknown VCID Type: The VCID Type is unknown. 356 (c) unknown flow-ID Type: the flow-ID Type is unknown. 358 When the downstream node accepts the OFFER message from the upstream 359 node, it must send a READY message to the upstream node within the 360 refresh interval offered by the upstream node. If it can not, the 361 downstream node sends the ERROR message (this refresh interval is not 362 supported) to the upstream node. The downstream node should accept 363 the refresh interval larger than 120 seconds. Therefore the 364 downstream node shouldn't send the ERROR message (this refresh 365 interval is not supported) when the refresh interval in the OFFER 366 message is larger than 120 seconds. 368 The following describes the procedure of the node which has received 369 an OFFER message. 371 1. if(unknown version in the OFFER message) 372 then Discard the message. Goto end. 374 2. if(unknown VCID Type in the OFFER message) 375 then Send an ERROR (unknown VCID Type) message. Goto end. 377 3. if(VCID in the OFFER message has not been registered) 378 then Send an ERROR (unknown VCID) message. Goto end. 380 4. if(unknown Flow ID Type in the OFFER message) 381 then Send an ERROR (unknown Flow ID Type) message. Goto end. 383 5. if(refuse Flow ID in the OFFER message) 384 then Send an ERROR (refused by policy) message. Goto end. 386 6. if(refuse refresh interval in the OFFER message) 387 then Send an ERROR(This refresh interval is not supported) 388 message. Goto end. 390 7. if(the mapping between Flow ID and VCID already exists and 391 Flow ID in the OFFER message is different from the registered 392 Flow ID for the corresponding VCID) 393 then Do Flow-ID removal procedure. Goto end. 395 8. Do the procedure of receiving the OFFER message. 397 7. if(successful) 398 then Send a READY message. 399 else Send an ERROR (resource unavailable) message. 401 8. end. 403 The procedure of the node which has received a READY message is 404 described. 406 1. if(unknown version in the READY message) 407 then Discard the message. Goto end. 409 2. if(unknown VCID Type in the READY message) 410 then Send an ERROR (unknown VCID Type) message. Goto end. 412 3. if(VCID in the READY message has not been registered) 413 then Send an ERROR (unknown VCID) message. Goto end. 415 4. if(unknown Flow ID Type in the READY message) 416 then Send an ERROR (unknown Flow ID Type) message. Goto end. 418 5. if((the mapping between Flow ID and VCID doesn't exist)|| 419 (the mapping between Flow ID and VCID already exists and 420 Flow ID in the READY message is different from registered Flow 421 ID for the corresponding VCID)) 422 then Send an ERROR (unknown VCID) message. Goto end. 424 6. Do the procedure of receiving the READY message. 426 7. end. 428 5.4 Flow ID Refresh Procedure 430 While the downstream node receives IP packets through the Dedicated- 431 VC, it should periodically (with a refresh interval) send the READY 432 message to the upstream node. When the downstream node does not 433 receive any IP packet during the refresh interval, it does not send 434 the READY message to the upstream node. 436 While the upstream node continues to receive READY messages, it 437 realizes that it can transmit the IP packets through the Dedicated- 438 VC. When it does not receive a READY message at all for a 439 predetermined period (dead interval), it removes the mapping between 440 the Flow IP and VCID. The dead interval is defined below. 442 When the upstream node falls into failure without the Flow ID removal 443 procedure for a Dedicated-VC, its mapping must be removed by the 444 downstream node. The downstream node removes the mapping between the 445 Flow ID and VCID for the Dedicated-VC when it does not receive any IP 446 packet for a "removal period" (=refresh interval times m). 448 The refresh interval, the dead interval and the removal period should 449 satisfy the following equation. 451 refresh interval < dead interval < removal period (=refresh 452 interval times m) 454 The recommended values are: 455 refresh interval = 2 minutes 456 dead interval = 6 minutes (=refresh interval x 3) 457 removal period = 20 minutes (=refresh interval x 10) 459 5.5 Flow ID Removal Procedure 461 When the upstream node realizes that the Dedicated-VC is not used, it 462 performs a Flow ID removal procedure. 464 The Flow ID removal procedure differs between the case of PVC/VP 465 configuration and the case of SVC configuration. 467 With the PVC/VP configuration, the upstream node issues a REMOVE 468 message to the downstream node, and the downstream node sends back a 469 REMOVE ACK message to the upstream node. The upstream node 470 retransmits REMOVE messages when it does not receive a REMOVE ACK 471 message. The upstream node assumes that the downstream node is in 472 failure state when it dose not receive any REMOVE ACK message from 473 the downstream node even with five REMOVE message retransmissions. 475 With SVC configuration, two procedures are possible. One is that the 476 mapping between the Flow ID and the VCID is removed without the 477 release of the ATM connection, which is the same procedure as the 478 PVC/VP configuration. The other procedure is that the mapping 479 between the Flow ID and the VCID is removed by releasing the VC 480 through ATM signaling. The former procedure can promptly create and 481 delete the mapping between Flow ID and VCID, since the ATM signaling 482 does not have to be performed each time. However, an un-used ATM 483 connections have to be maintained by the node. Which procedure is 484 applied to is a matter of each CSR's local decision, taking the VC 485 resource cost and responsiveness into account. 487 The downstream node may want to remove the mapping between the Flow 488 ID and the VCID. When the upstream node receives the REMOVE message, 489 it sends a REMOVE ACK message to the downstream node. 491 +--+ +--+ 492 |R1|------------------------------|R2| 493 +--+ +--+ 494 | PROPOSE | 495 |===============================>| 496 VCID | [VCID, target IP] | 497 negotiation | PROPOSE ACK | 498 |<===============================| 499 | [VCID] | 500 | | 501 | OFFER | 502 |===============================>| 503 Flow-ID | [VCID, flow-ID] | 504 notification | READY | 505 |<===============================| 506 | [VCID, flow-ID] | 507 | | 508 : : : 509 : : : 510 | READY | 511 |<===============================| 512 Dedicated-VC | [VCID, flow-ID] | 513 refresh | READY | 514 |<===============================| 515 | [VCID, flow-ID] | 517 Figure 2. Flow ID notification and refresh procedure 519 +--+ +--+ 520 |R1|------------------------------|R2| 521 +--+ +--+ 522 | | 523 | REMOVE | 524 |================================>| 525 | [VCID] | 526 | | 527 | REMOVE ACK | 528 |<================================| 529 | [VCID] | 531 (a) Flow ID removal (independent of ATM signaling) 533 +--+ +--+ 534 |R1|------------------------------|R2| 535 +--+ +--+ 536 | ATM signaling | 537 | (release) | 538 |<===============================>| 539 | | 541 (b) Flow ID removal through ATM signaling 543 Figure 3. Flow ID removal procedure 545 6. Message Format 547 FANP control procedure includes seven messages described from 6.2 to 548 6.8. Among them, a PROPOSE message used for VCID negotiation 549 procedure uses an extended ATM ARP message format defined in RFC1577 550 [2]. The other messages are encapsulated into IP packets. 552 The destination IP address in the IP packet header signifies the 553 neighbor node's IP address and the source IP address signifies 554 sender's IP address. Currently, the protocol ID for these messages 555 is 110(decimal). This protocol ID must be registered by IANA. 557 The reserved field in the following packet format must be zero. 559 6.1 Field Format 561 6.1.1 VCID field 563 VCID type value decides VCID field format. Currently, only type "1" 564 is defined. The VCID field format of VCID type 1 is shown below. 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | ESI of upstream node | 570 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 573 | ID | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 ESI field: ESI of upstream node 577 ID : upstream node decides unique identifier. 579 6.1.2 Flow ID field 581 Flow ID type value decides flow-ID field format. Currently, flow-ID 582 type "0" and "1" are defined. The flow ID type value "0" signifies 583 that the flow ID field is null. When flow ID type value is "1", the 584 format shown below is used. 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Source IP address | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Destination IP address | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 Source IP address : source IP address of flow 595 Destination IP address : destination IP address of flow 597 6.2 PROPOSE message 599 PROPOSE message uses the extended ATM-ARP message format [2] to which 600 the VCID type and the VCID field are added. Type & Length fields are 601 set to zero, because the messages don't need sender/target ATM 602 address. This message is transferred from the upstream node to the 603 downstream node through the Dedicated-VC. 605 PROPOSE message is transferred from the upstream node to the 606 downstream node through the Dedicated-VC. 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Hardware Type = 0x13 | Protocol Type = 0x0800 | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Type&Length 1 | Type&Length 2 | Opereation Code | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Length 1 | Type&Length 3 | Type&Length 4 | Length 2 | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Sender IP Address | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Target IP Address | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | VCID Type |VCID Length | Reserved | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | VCID | 624 / / 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Type&Length 1 ; Type & Length of sender ATM number = 0 628 Type&Length 2 ; Type & Length of sender ATM subnumber = 0 629 Type&Length 3 ; Type & Length of sender ATM number = 0 630 Type&Length 4 ; Type & Length of sender ATM subnumber =0 631 Length 1 ; Source IP address length 632 Length 2 ; Target IP address length 634 Operation code 635 0x10 = PROPOSE 637 VCID Type: Currently , VCID Type = 1 is defined. 638 VCID Length: Length of VCID field 639 VCID : VCID described previous 641 6.3 PROPOSE ACK 643 PROPOSE ACK messages is transferred through the Default-VC. 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Version |Op code = 1 | Checksum | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | VCID type |Flow-ID type=0 | Reserved | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | VCID | 653 / / 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Version 657 This field indicates the version number of FANP. Currently, 658 Version = 1 660 Operation Code 661 This field indicates the operation code of the message. There 662 are five operation codes, below. 664 operation code = 1 : PROPOSE ACK message 666 Checksum 667 This filed is the 16 bits checksum for whole body of FANP 668 message. The checksum algorithm is same as the IP header. 670 VCID Type 671 This field indicates the VCID type. Currently, only "1" is 672 defined. 674 6.4 OFFER message 676 OFFER message is transferred from an upstream node to a downstream 677 node. The following is the message format. 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Version = 1 | Op Code = 2 | Checksum | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | VCID type |Flow-ID type | Refresh Interval | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | VCID | 687 / / 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Flow-ID | 690 / / 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Refresh Interval 694 This field indicates the interval of refresh timer. The refresh 695 interval is represented by second in integer. This field is 696 used only in OFFER message. Recommended value is 120 (second). 698 6.5 READY message 700 READY message is transfered from a downstream node to an upstream 701 node. This message is transferred when the downstream node receives 702 OFFER message. And this message is transferred periodically in each 703 refresh interval. The following is the message format. 705 0 1 2 3 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Version = 1 | Op Code = 3 | Checksum | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | VCID type |Flow-ID type | Reserved | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | VCID | 713 / / 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Flow-ID | 716 / / 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 6.6 ERROR message 721 ERROR message is transfered from a downstream node to an upstream 722 node or from an upstream node to a downstream node. This message is 723 transferred when some of the fields in the receive message is unknown 724 or refused. When the receive message is the ERROR message, ERROR 725 message isn't sent. VCID type ,VCID, Flow ID Type and Flow ID field 726 in the ERROR message are filled with the same field in the receive 727 message. 729 The following is the message format. 731 0 1 2 3 732 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 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Version = 1 | Op Code = 4 | Checksum | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | VCID type |Flow-ID type | Error code | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | VCID | 739 / / 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Flow-ID | 742 / / 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Error Code = 1 : unknown VCID type 746 = 2 : unknown Flow-ID type 747 = 3 : unknown VCID 748 = 4 : resource is unavailable 749 = 5 : unavailable refresh interval is offered 750 = 6 : refuse by policy 752 6.7 REMOVE message 754 REMOVE message is transfered from a downstream node to an upstream 755 node or vice versa. This message is transferred to remove the 756 mapping relationship between the flow ID and and the VCID. The node 757 which receives REMOVE message must send REMOVE ACK message, even when 758 VCID in the receive message isn't known . 760 The following is the message format. 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Version = 1 | Op Code = 5 | Checksum | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | VCID type |Flow-ID type | Reserved | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | VCID | 770 / / 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 6.8 REMOVE ACK message 775 REMOVE ACK message is transferred from a downstream node to an 776 upstream node or from an upstream node to a downstream node. The 777 following is the message format. 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Version = 1 | Op Code = 6 | Checksum | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | VCID type |Flow-ID type | Reserved | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | VCID | 787 / / 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 7. Security Considerations 792 Security issues are not discussed in this memo. 794 8. References 796 [1] Y.Katsube, K.Nagami, H.Esaki, "Router Architecture Extensions 797 for ATM; overview", IETF Internet-Dreaft, 798 draft-rfced-info-katsube-00.txt, Oct. ,1996. 800 [2] M.Laubach, "Classical IP and ARP over ATM", IETF RFC1577, 801 Oct.,1993. 803 [3] Juha Heinanen, "Multiprotocol Encapsulation over ATM Adaptation 804 Layer 5", IETF RFC1483,July.,1993. 806 Ethernet is a registered trademark of Xerox Corp. All other product 807 names mentioned herein may be trademarks of their respective 808 companies. 810 9. Authors' Addresses 812 Ken-ichi Nagami 813 R&D Center, Toshiba 814 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan 815 Phone : +81-44-549-2238 816 EMail : nagami@isl.rdc.toshiba.co.jp 818 Yasuhiro Katsube 819 R&D Center, Toshiba 820 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan 821 Phone : +81-44-549-2238 822 EMail : katsube@isl.rdc.toshiba.co.jp 824 Yasuro Shobatake 825 R&D Center, Toshiba 826 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan 827 Phone : +81-44-549-2238 828 Email : masahata@csl.rdc.toshiba.co.jp 830 Akiyoshi Mogi 831 R&D Center, Toshiba 832 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan 833 Phone : +81-44-549-2238 834 EMail : mogi@isl.rdc.toshiba.co.jp 836 Shigeo Matsuzawa 837 R&D Center, Toshiba 838 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan 839 Phone : +81-44-549-2238 840 EMail : shigeom@isl.rdc.toshiba.co.jp 842 Tatsuya Jinmei 843 R&D Center, Toshiba 844 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan 845 Phone : +81-44-549-2238 846 EMail : jinmei@isl.rdc.toshiba.co.jp 848 Hiroshi Esaki 849 R&D Center, Toshiba 850 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan 851 Phone : +81-44-549-2238 852 EMail : hiroshi@isl.rdc.toshiba.co.jp