idnits 2.17.1 draft-nagami-csr-fanpv2-dcmode-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-19) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 4 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 667: '... following packet format MUST be zero....' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'VCID' on line 633 -- Looks like a reference, but probably isn't: 'FlowID' on line 589 -- Looks like a reference, but probably isn't: 'LLID' on line 633 ** Downref: Normative reference to an Informational RFC: RFC 2098 (ref. '1') -- No information found for draft-katusbe-csr-arch - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 1483 (ref. '5') (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1577 (ref. '6') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft 2 Expiration Date: June 1998 Ken-ichi Nagami 3 Yasuhiro Katsube 4 Shigeo Matsuzawa 5 Akiyoshi Mogi 6 Koutarou Ise 8 Toshiba 10 Flow Attribute Notification Protocol Version 2 (FANPv2) 11 Distributed Control Mode 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 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference 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 describes the specification of FANPv2 (Flow Attribute 36 Notification Protocol version 2) distributed control mode (DC-mode). 37 The FANPv2 is a protocol used by Cell Switch Routers (CSRs) to 38 communicate mapping information between a specific packet flow and a 39 virtual connection that conveys the packet flow. In the DC-mode, 40 the control message exchange for a packet flow between each pair of 41 neighboring CSRs is initiated independently from the message 42 exchange for the same flow between any other pair of CSRs. The 43 DC-mode is applicable to the control of both unicast and multicast 44 cut-through paths. 46 1. Introduction 48 The FANPv2 is a protocol used by Cell Switch Routers (CSRs)[1] to 50 Nagami, et al. [Page 1] 51 communicate mapping information between a specific packet flow and a 52 virtual connection that conveys the packet flow. This draft 53 describes the specification of FANPv2 distributed control mode 54 (DC-mode), which is one of the two modes provided by the FANPv2 as 55 described in [2]. 57 In the DC-mode, the control message exchange for a packet flow 58 between each pair of neighboring CSRs is initiated independently 59 from the message exchanges for the same flow between any other pair 60 of CSRs. The DC-mode is applicable to the control of both unicast 61 and multicast cut-through paths. 63 The following descriptions assume ATM as a cut-through switching 64 technology although the protocol mechanism can be applied to the 65 other switching technologies such as frame-relay. 67 2. Terminology and Definitions 69 o VCID (Virtual Connection IDentifier) [8] 70 An identifier of a virtual connection (ATM VC or VP) that 71 is uniquely recognized by neighboring nodes. 72 In the case that the VPI/VCI values at both endpoints of the 73 VC are not the same, the VCID value is composed of the ESI 74 (End System Identifier) of either of the neighboring nodes 75 and the unique identifier within the node. In the case that 76 the VPI/VCI value at one endpoint of a VC is maintained at 77 another endpoint, the VPI/VCI value can be used as a VCID. 79 o Cut-through forwarding 80 Packet forwarding based on VPI/VCI values without layer 3 81 processing at the CSR. 82 Layer 3 information (e.g., destination IP address) is 83 associated with the corresponding VPI/VCI by using FANP. 85 o Hop-by-Hop forwarding 86 Packet forwarding based on layer 3 information like that of 87 conventional routers. In ATM, cells are re-assembled into 88 packets at the router, whose layer 3 headers are analyzed for 89 making a forwarding decision. 91 o Default-VC 92 A VC that is used for hop-by-hop forwarding. Cells received 93 from the Default-VC are reassembled into packets. 94 Conventional layer 3 processing is performed for these packets. 95 Control packets such as routing messages and FANP messages 96 are also transmitted over this VC. 98 o Dedicated-VC 100 Nagami, et al. [Page 2] 101 A VC that is used for a specific packet flow. When the 102 FlowID for an incoming VC and that for an outgoing VC are the 103 same at a CSR, it can forward the packets belonging to the 104 flow with the cut-through forwarding. 106 o Cut-through path 107 A sequence of dedicated-VCs which transmit packets belonging 108 to the same FlowID with the cut-through forwarding. 110 o FlowID (Flow IDentifier) 111 A set of parameters that identify a specific packet flow. 112 For example, an end-to-end layer 3 flow is identified by the 113 FlowID that contains a source IP address and a destination 114 IP address. 116 3. Cut-through Path Control Procedure 118 3.1 Overview of the Distributed Control Mode (DC-mode) 120 In the DC-mode, the cut-through path establishment procedure for a 121 packet flow is initiated at individual nodes on its path in a 122 distributed manner. Each of them transmits FANP control messages to 123 its downstream neighbor in order to notify the mapping relationship 124 between the packet flow and the outgoing dedicated-VC that will 125 convey the flow. The downstream node that has received the control 126 message from its upstream neighbor memorizes the received mapping 127 information at its incoming interface, and transmits an 128 acknowledgment to its upstream neighbor. 130 This message exchange with an upstream neighbor at the node does not 131 initiate the exchange of any control messages with its downstream 132 neighbor. A control message exchange for a flow between a pair of 133 CSRs is initiated and carried out independently from the message 134 exchange for the same flow between any other pair of nodes. 136 As a result of control message exchanges performed at individual 137 pairs of nodes, a node can perform cut-through packet forwarding 138 when it realizes that both the incoming dedicated-VC and the 139 outgoing dedicated-VC are associated with the same FlowID. 141 The cut-through path release procedure is also initiated at 142 individual nodes on the path. A node that has detected the trigger 143 to release the cut-through path transmits FANP control messages to 144 its downstream neighbor in order to cancel the mapping relationship 145 between the packet flow and the outgoing dedicated-VC that conveys 146 the flow. The reception of the control messages from the upstream 147 neighbor and the cancellation of the mapping relationship at an 148 incoming interface of a node do not become the trigger for the 150 Nagami, et al. [Page 3] 151 control message transmission toward its downstream neighbor. 153 Although concrete parameters for the cut-through establishment or 154 release trigger are not specified in this document, generic control 155 procedures in the case of two typical types of trigger 156 (traffic-driven and request-driven control) are described below. 158 This subsection describes cut-through path control procedure for the 159 case that neighboring nodes are interconnected by the point-to-point 160 link for simplicity. Procedures in the case that the neighboring 161 nodes are interconnected over other types of ATM datalink are 162 described in 3.2. 164 3.1.1 Traffic-driven Operation 166 3.1.1.1 Path Establishment / Release 168 Figure 1 shows a traffic-driven path establishment procedure for 169 unicast packet transmission from a sender H1 to a receiver H2. 170 Ingress edge router R1, CSR core router R2, and egress edge router 171 R3 are assumed to speak FANPv2 protocol. 173 Ingress edge router R1 transmits packets toward its downstream 174 neighbor R2 over a default-VC as a default behavior. When R1 decides 175 that a packet flow satisfies specific conditions for cut-through 176 path establishment, it initiates the path establishment 177 procedure. It selects a dedicated-VC for the packet flow, then 178 transmits a NOTIFY message, that notifies its downstream neighbor R2 179 of the mapping relationship between the packet flow and the selected 180 dedicated-VC, to R2. The identifier of the packet flow (FlowID) is 181 assumed to be source IP address H1 and destination IP address H2 182 (H1, H2). When R2 accepts the NOTIFY message sent by R1, it 183 transmits a NOTIFY ACK message to R1, which concludes a flow 184 notification step between R1 and R2. 186 Similarly, when R2 decides that the same packet flow as above 187 satisfies specific conditions for cut-through path establishment, it 188 selects a dedicated-VC that conveys the flow, then transmits a 189 NOTIFY message, that notifies its downstream neighbor R3 of the 190 mapping relationship between the flow and selected dedicated-VC, to 191 R3. When R3 accepts the NOTIFY message sent by R2, it transmits 192 NOTIFY ACK message to R2, which concludes a flow notification step 193 between R2 and R3. When R2 realizes that both the incoming 194 dedicated-VC from R1 and the outgoing dedicated-VC to R3 are 195 associated with the same flow, it can begin cut-through packet 196 transmission by concatenating the incoming and the outgoing 197 dedicated-VC at ATM level. 199 Nagami, et al. [Page 4] 200 Release of the cut-through paths is also performed by individual 201 nodes that have detected triggers to release the path. Each of them 202 transmits a REMOVE message, that notifies its downstream neighbor of 203 removal of the mapping relationship between the packet flow and the 204 dedicated-VC. The downstream node transmits a REMOVE ACK message to 205 the upstream node, which concludes a flow removal step between 206 neighboring nodes. Note that the removal of the mapping 207 relationship for a packet flow at an incoming interface of a node 208 does not initiate the flow removal step for the same flow at its 209 outgoing interface. 211 Examples of the trigger for cut-through path establishment and 212 release are shown below. One or several of them could be selected as 213 well as other triggers that are not itemized below. It is desirable 214 that the common triggers are adopted in a domain. 216 Establishment Trigger: 217 - Transmission of a packet with specific upper layer protocols 218 defined by the port-ID of TCP/UDP. 219 (ex. http, ftp, and nntp) 220 - Transmission of a TCP SYN packet. 221 - Transmission of a packet with specific source/destination 222 IP addresses. 223 - Transmission of more than a certain amount of packets in a 224 predetermined period. 226 Release Trigger: 227 - Decrease of the packet activity (no packet or less than a 228 certain amount of packets in a predetermined period). 229 - Change of a next-hop entry in a routing table related to 230 an active cut-through path. 231 - Recognition that a neighbor node isn't running through the 232 neighbor discovery protocol [4]. 234 A similar procedure is applicable to a traffic-driven multicast 235 case. When establishing a multicast cut-through path, each node on 236 the multicast tree selects a dedicated-VC toward each of its 237 downstream neighbors, and then transmits a NOTIFY message, that 238 conveys a mapping relationship between the multicast packet flow and 239 the selected dedicated-VC, to each neighbors. The identifier of the 240 multicast packet flow (FlowID) would be source IP address and 241 multicast group address in the case that the source tree-based 242 multicast routing (e.g., DVMRP) is applied, while it would be IP 243 address of the core node and multicast group address in the case 244 that the core-based multicast routing (e.g., PIM-SM) is applied. 246 Trigger for cut-through establishment, e.g., transmission of 247 multicast packet, is detected by each node in a manner similar to 248 the unicast case. When a node has found a new multicast group member 250 Nagami, et al. [Page 5] 251 at one of its outgoing interfaces that was not the leaf of the tree, 252 it performs the same procedure as the initial establishment toward 253 the downstream neighbor at the interface. When a node, on the 254 contrary, has recognized that a multicast group member has left the 255 group at one of its outgoing interface, it performs the same 256 procedure as the release of the cut-through toward the downstream 257 neighbor at the interface. 259 3.1.1.2 Operation for Route Changes 261 When a node has recognized a change of the next-hop (downstream 262 neighbor) node for an active cut-through path, it stops cut-through 263 forwarding and transmits a REMOVE message to cancel the mapping 264 relationship for the related packet flow. The downstream node that 265 has received the REMOVE message sends back a REMOVE ACK message, but 266 does not perform the flow removal action toward its downstream 267 neighbor unless its own next-hop entry for the packet flow has been 268 changed. It will perform the flow removal action toward the 269 downstream neighbor if there is no packet activity from the upstream 270 neighbor. 272 The node that has completed the flow removal action toward the old 273 downstream neighbor performs the path establishment procedure toward 274 the new downstream neighbor by one of the establishment triggers 275 (e.g., transmission of a packet with specific upper layer 276 protocols). 278 +--+ Ethernet +--+ +-----+ +--+ +-----+ +--+ Ethernet +--+ 279 |H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2| 280 +--+ +--+ +-----+ +--+ +-----+ +--+ +--+ 281 trigger pkt 282 |----------> trigger packet 283 |-------------> trigger packet 284 NOTIFY |--------------> trigger pkt 285 ==============> NOTIFY |-----------> 286 NOTIFY ACK ===============> 287 <============== NOTIFY ACK 288 <=============== 289 |=============| 290 Dedicated-VC |==============| 291 Dedicated-VC 293 Figure 1. 295 3.1.2 Request-driven Operation 297 Nagami, et al. [Page 6] 298 3.1.2.1 Path Establishment/Release 300 Figure 2 shows a request-driven path establishment procedure for 301 packet transmission from a sender H1 to a receiver H2. The procedure 302 between neighboring nodes is the same as in the traffic-driven case. 303 The difference is that the trigger for the path establishment or 304 release is not related to the data packets but to the control 305 packets such as the RSVP messages[7]. 307 In the case that the path establishment or release is triggered by 308 the RSVP messages, a cut-through path is established from downstream 309 to upstream along with the RSVP reservation (Resv) messages. R2 310 that has received a Resv message from R3 performs the flow 311 notification procedure by selecting a dedicated-VC for the requested 312 flow and transmitting a NOTIFY message to R3. R2 realizes that the 313 flow notification procedure has succeeded when it receives a 314 NOTIFY ACK message from R3, and then transmits a Resv message to its 315 upstream neighbor R1. R1 that has received Resv message from R2 316 performs the flow notification procedure between R2 similarly. R2, 317 as a result, realizes that both the incoming dedicated-VC from R1 318 and the outgoing dedicated-VC toward R3 are associated with the same 319 packet flow, and then is able to begin cut-through forwarding. 321 Release of the cut-through paths is also performed by individual 322 nodes that have recognized expiration of RSVP's reservation state. 323 Each of them transmits a REMOVE message, that notifies its 324 downstream neighbor of removal of the mapping relationship. The 325 expiration of the RSVP reservation state is detected by either 326 the reception of RSVP reservation tear message or the timeout of the 327 state refresh period. 329 Examples of the trigger for cut-through path establishment and 330 release in the request-driven case are shown below. 332 Establishment Trigger: 333 - Establishment of the RSVP reservation state. 335 Release Trigger: 336 - Expiration of the RSVP reservation state. 337 - Recognition that a neighbor node isn't running through the 338 neighbor discovery protocol. 340 Nagami, et al. [Page 7] 341 +--+ Ethernet +--+ +-----+ +--+ +-----+ +--+ Ethernet +--+ 342 |H1|----------|R1|---| ATM |---|R2|---| ATM |---|R3|----------|H2| 343 +--+ +--+ +-----+ +--+ +-----+ +--+ +--+ 344 Resv 345 <----------| 346 Resv 347 Resv <--------------| 348 Resv <-------------| NOTIFY 349 <----------| NOTIFY ===============> 350 ==============> NOTIFY ACK 351 NOTIFY ACK <=============== 352 <=============| 353 |==============| 354 |=============| Dedicated-VC 355 Dedicated-VC 357 Figure 2. 359 3.1.2.2 Operation for Route Changes 361 In the operation driven by RSVP, unlike the case of the 362 traffic-driven operation, a change of the next-hop node for the 363 packet flow with cut-through forwarding does not initiate the 364 procedure for changing the route of the cut-through path. Since the 365 RSVP process itself has a functionality to determine the reservation 366 path, e.g., route pinning, it is desirable that the route of the 367 RSVP flow is controlled by the RSVP process rather than the native 368 routing process. 370 3.2 Procedure Dependent on Datalink Type 372 A previous subsection described the cut-through path control 373 procedure for the case that neighboring FANP-capable nodes are 374 interconnected by the point-to-point link for simplicity. In 375 addition to the point-to-point link, it should be possible for the 376 nodes to be interconnected over various types of datalink such as 377 ATM networks that provide SVC services. 379 This subsection describes FANP procedures between neighboring nodes 380 which are interconnected over various types of ATM network as well 381 as by the point-to-point link. 383 3.2.1 Operational Overview 385 The FANP procedure between neighboring nodes is composed of : 386 (1)Dedicated-VC setup, (2)VCID notification, and (3)Flow 388 Nagami, et al. [Page 8] 389 notification for cut-through establishment, and (4)Flow removal, 390 (5)VCID removal, and (6)Dedicated-VC release for cut-through 391 teardown. 393 (1) Dedicated-VC setup : 394 It is performed only when the neighboring nodes are 395 interconnected over an ATM SVC network. An upstream node 396 establishes a dedicated-VC, by using ATM signaling procedure, so 397 as to be used as a cut-through path. 399 (2) VCID notification : 400 It is performed in the case that the VPI/VCI value of the cell 401 transmitted by the upstream node and that of the cell received 402 by the downstream node are not the same. Association between a 403 dedicated-VC and "VCID", which is being commonly recognized by 404 the neighboring nodes terminating the VC, is established at this 405 step. One of the following two types of procedure is performed 406 depending on the types of ATM network: i)use of an inband 407 message (PROPOSE message) that is transmitted over the 408 dedicated-VC being used, ii)use of a message (NOTIFY message) 409 that associates an Information Element (IE) conveyed by an ATM 410 signaling with a VCID value. 412 (3) Flow notification : 413 It is the core procedure that lets the neighboring nodes share 414 the common knowledge about mapping relationship between a packet 415 flow (FlowID) and a VCID. An upstream node notifies a 416 downstream node of the mapping relationship (NOTIFY message), 417 which is acknowledged by the downstream node (NOTIFY ACK 418 message). VCID notification and flow notification can be merged 419 into a single message when the two actions are performed 420 consecutively (see 3.2.5.1). 422 (4) Flow removal : 423 It is performed to cancel the registered mapping relationship 424 between a packet flow and a VCID. An upstream node transmits a 425 REMOVE_FLOW or REMOVE_ALL message to a downstream node, which is 426 acknowledged by the downstream node. The latter message is used 427 to perform the flow removal and the VCID removal (described 428 below) at once. 430 (5) VCID removal : 431 It is performed to cancel the association between the 432 dedicated-VC and the VCID allocated at the VCID notification 433 step. 435 (6) Dedicated-VC release : 436 It is performed only when the neighboring nodes are 437 interconnected over an ATM SVC network. An upstream node 439 Nagami, et al. [Page 9] 440 releases a dedicated-VC, by using ATM signaling procedure. 442 The following four types of datalink which interconnect neighboring 443 FANP-capable nodes are possible: 445 (a) Point-to-point link that interconnects neighboring nodes directly 446 (b) PVC-based ATM network 447 (c) VP-based ATM network that provides logical point-to-point link 448 (d) SVC-based ATM network 450 Some of the above-mentioned procedural steps (e.g., dedicated-VC 451 setup and VCID notification) could be omitted in the case of certain 452 datalink types, while all of the steps should be executed in the 453 case of other datalink types. Detailed procedures for individual 454 datalinks are described from 3.2.2 to 3.2.5. 456 Note that the FANP procedure will not work until each node 457 recognizes its neighbor nodes as FANP-capable through the neighbor 458 discovery protocol specified in [4]. Any messages received from an 459 unrecognized neighbor node must be discarded. 461 All the messages described in this section have a Sender ID and a 462 Receiver ID field except for a PROPOSE message. Each node should 463 fill in each of these fields with a Local ID and a Peer ID in its 464 neighbor table[4], respectively. If a Sender ID or a Receiver ID in 465 the received message is different from the Peer ID or the Local ID 466 in the neighbor table, the message must be discarded. All the FANP 467 messages except for a PROPOSE message are conveyed over a 468 default-VC. 470 3.2.2 Operation over Point-to-point Link 472 In the operation over the point-to-point link, neither the 473 dedicated-VC setup nor the dedicated-VC release is necessary since 474 there is no conventional ATM switch between neighboring 475 nodes. Neither the VCID notification nor the VCID removal is 476 necessary since the VPI/VCI value of an outgoing cell at an upstream 477 node and that of an incoming cell at a downstream node are the same 478 in this case. 480 When an upstream node has detected cut-through establishment trigger 481 for a packet flow, it determines VPI/VCI value of an available 482 dedicated-VC, and then transmits a NOTIFY[VCID, FlowID] message, 483 that conveys the VPI/VCI value as a VCID and the FlowID of the 484 packet flow, to its downstream neighbor node. The downstream node 485 sends back either an NOTIFY ACK or an ERROR message to the upstream 486 node. 488 The upstream node periodically retransmits the NOTIFY[VCID, FlowID] 489 message when it has received neither a NOTIFY ACK nor an ERROR 490 message in a certain period of time. When it has not received any 491 response after a number of retransmissions, it proceeds to a flow 492 removal procedure described below. Default value of the 493 retransmission interval and the number of retransmissions are 494 described in Appendix C. 496 When an upstream node has detected cut-through release trigger for a 497 cut-through packet flow, it transmits a REMOVE_FLOW message, that 498 includes a VCID value, to the downstream node. The downstream node 499 sends back a REMOVE_FLOW ACK message to the upstream node. The 500 upstream node periodically retransmits the REMOVE_FLOW message when 501 it has not received REMOVE_FLOW ACK message in a certain period of 502 time. Default value of the retransmission interval is described in 503 Appendix C. 505 3.2.3 Operation over ATM PVC 507 In the operation over ATM PVC network, a certain amount of PVCs is 508 provided between neighboring nodes as an initialization procedure. 509 One of the unused PVCs is picked up as a dedicated-VC when a node 510 detects cut-through establishment trigger. As the VPI/VCI value of 511 an outgoing cell at an upstream node and that of an incoming cell at 512 a downstream node are not the same in general, it is necessary that 513 the dedicated-VC is given a VCID which can be uniquely identified by 514 both endpoints of the VC (VCID notification). 516 An upstream side of the PVC transmits a PROPOSE message to a 517 downstream side over the selected PVC itself, which conveys the VCID 518 value being allocated to the PVC. The downstream node sends back a 519 PROPOSE ACK message to the upstream node over a default-VC, which 520 concludes the VCID notification step. 522 The upstream node periodically retransmits the PROPOSE message when 523 it has received neither a PROPOSE ACK nor a PROPOSE NACK message in 524 a certain period of time. When it has not received any response 525 after a number of retransmissions, it proceeds to a VCID removal 526 procedure described below. Default value of the retransmission 527 interval and the number of retransmissions are described in Appendix 528 C. 530 After the VCID notification procedure has been successfully 531 completed, the flow notification and removal can be performed with 532 the same procedure as the point-to-point link case described in 533 3.2.2. The VCID notification procedure can be performed immediately 534 after the setup of the PVCs at the initialization phase, or when the 535 cut-through establishment trigger is detected. 537 The VCID value allocated to the PVC at the VCID notification step 538 can be released by the VCID removal procedure. The upstream node 539 transmits a REMOVE_ALL message to the downstream node, which is 540 acknowledged by the downstream node with a REMOVE_ALL ACK message. 541 The upstream node periodically retransmits the REMOVE_ALL message 542 when it has not received REMOVE_ALL ACK message in a certain period 543 of time. Default value of the retransmission interval is described 544 in Appendix C. 546 3.2.4 Operation over ATM VP 548 In the operation over ATM VP network, one or several ATM VPs are 549 provided between neighboring nodes as an initialization procedure. 550 One of the unused VCIs is picked up as a dedicated-VC when a node 551 detects cut-through establishment trigger. 553 When a single VP is provided between neighboring nodes, all the 554 procedures are the same as in the case of the point-to-point link 555 operation described in 3.2.2 since the VCI value of an outgoing cell 556 at an upstream node and that of an incoming cell at a downstream 557 node are the same. When multiple VPs are provided between 558 neighboring nodes, on the other hand, the VCID notification step is 559 necessary in order that both nodes recognize which VPI as well as 560 VCI is going to be used as a dedicated-VC. 562 3.2.5 Operation over ATM SVC 564 In the operation over ATM SVC network, dedicated-VCs as well as 565 default-VCs are provided through the ATM signaling. Procedures for 566 cut-through establishment and release differ depending on, 567 (i)whether the BLLI(Broadband Low Layer Information) IE is available 568 in the underlying ATM signaling, and (ii)whether the SVC for a 569 dedicated-VC is set up each time the cut-through establishment 570 trigger is detected or a number of surplus SVCs are prepared (VC 571 pool[9]), one of which is picked up when the cut-through 572 establishment trigger is detected. 574 3.2.5.1 On-demand SVC Setup with BLLI IE 576 When an upstream node detects the cut-through establishment trigger, 577 it selects an available temporal ID value called LLID (Low Layer ID) 578 and an available VCID value, both of which are identifiers of a 579 dedicated-VC to be set up, and then sets up a dedicated-VC by ATM 580 signaling. The upstream node conveys the selected 7-bit LLID value 581 in the "user specified layer 3 protocol information field" of the 582 BLLI IE of a SETUP message. When the SVC setup has been completed, 583 both the upstream and the downstream node memorize the LLID value as 584 an identifier of the SVC. 586 Then the upstream node transmits a NOTIFY[LLID, VCID, FlowID] 587 message to the downstream node, which functions as a VCID 588 notification and flow notification at the same time. At the time 589 that the NOTIFY[LLID, VCID, FlowID] message is acknowledged by the 590 downstream node, both nodes share the common knowledge about the 591 identifier "VCID" of the dedicated-VC and about the association 592 between the VCID and the "FlowID" that is the identifier of the 593 packet flow transmitted over the dedicated-VC. The LLID value can be 594 released at both nodes at this stage, and can be recycled for other 595 SVCs that are being set up. 597 When the upstream node detects the cut-through release trigger, it 598 transmits a REMOVE_ALL message to the downstream node, which 599 functions as a flow removal and VCID removal at the same time. Then 600 the SVC is released by the ATM signaling. 602 3.2.5.2 On-demand SVC Setup without BLLI IE 604 When the upstream node detects the cut-through establishment 605 trigger, it selects an available VCID value as an identifier of a 606 dedicated-VC to be set up, and then sets up a dedicated-VC by ATM 607 signaling. The temporal ID of the SVC, that is commonly recognized 608 by both nodes, is not able to be conveyed by the ATM signaling 609 message in this case. 611 When the SVC setup has been completed, the upstream node proceeds to 612 a VCID notification step and a flow notification step that are the 613 same as in the case of PVC described in 3.2.3. 615 The flow removal, VCID removal, and dedicated-VC release procedure 616 are the same as 3.2.5.1. 618 3.2.5.3 Operation with VC Pool 620 In the case that a number of surplus unused SVCs are prepared as a 621 pool, neighboring nodes do not have to perform the dedicated-VC 622 setup/release procedure nor the VCID notification/removal procedure 623 each time a specific cut-through establishment/release trigger is 624 detected. When the upstream node detects the trigger to prepare an 625 additional dedicated-VC as a pool, it initiates a dedicated-VC setup 626 procedure and a VCID notification procedure. 628 When the BLLI IE is supported by the ATM signaling, a temporal 629 identifier of the SVC is selected by the upstream node and is 630 conveyed by the SVC SETUP message as described in 3.2.5.1. Then the 631 upstream node transmits a NOTIFY[LLID, VCID] message to the 632 downstream node, which functions as a VCID notification. At the time 633 that the NOTIFY[LLID, VCID] message is acknowledged by the 634 downstream node, both nodes recognize that the new SVC, which is 635 identified by the VCID, is registered into a "VC pool" for future 636 use as a dedicated-VC. 638 When the BLLI IE is not supported by the ATM signaling, the upstream 639 node sets up an SVC without conveying its temporal identifier, and 640 then proceeds to a VCID notification step that uses an inband 641 PROPOSE message as described in 3.2.3. At the time that the PROPOSE 642 message is acknowledged by the downstream node, both nodes 643 recognize that the new SVC, which is identified by the VCID, is 644 registered into a "VC pool" for future use as a dedicated-VC. 646 One of the available SVCs in a VC pool is picked up as a 647 dedicated-VC when a cut-through path is being set up. The flow 648 notification and the flow removal procedures are the same as the 649 procedure for the point-to-point link described in 3.2.2. When the 650 association with a specific flow is canceled by the flow removal 651 procedure, the SVC is returned to a VC pool for future use. 653 4. Message Format 655 FANP control messages are encapsulated in IP packets except for VCID 656 notification messages. The protocol ID for these messages is 657 110(decimal). They are transfered through default-VC. They consist 658 of a common header and object fields. 660 VCID notification messages(PROPOSE, PROPOSE ACK, PROPOSE NACK) are 661 carried in the extended ATM-ARP messages defined in RFC1577[6]. A 662 PROPOSE message is transferred from the upstream node to the 663 downstream node through the dedicated-VC. PROPOSE ACK and PROPOSE 664 NACK messages are transferred from the downstream node to the 665 upstream node through the default-VC. 667 The reserved field in the following packet format MUST be zero. 669 4.1 VCID Notification Message 671 PROPOSE, PROPOSE ACK and PROPOSE NACK messages are used for VCID 672 notification procedure. They use the extended ATM-ARP message 673 format [6] to which the VCID type and the VCID field are added. 674 Type & Length fields are set to zero, because the messages don't 675 need sender/target ATM address. 677 PROPOSE message is transferred from the upstream node to the 678 downstream node through the dedicated-VC. PROPOSE ACK and PROPOSE 679 NACK messages are transferred from the downstream node to the 680 upstream node through the default-VC. 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Hardware Type = 0x13 | Protocol Type = 0x0800 | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Type&Length 1 | Type&Length 2 | Operation Code | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Length 1 | Type&Length 3 | Type&Length 4 | Length 2 | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Sender IP Address | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Target IP Address | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | VCID Type |VCID Length | Reserved | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | VCID | 698 / / 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Type&Length 1 ; Type & Length of sender ATM number = 0 702 Type&Length 2 ; Type & Length of sender ATM subnumber = 0 703 Type&Length 3 ; Type & Length of sender ATM number = 0 704 Type&Length 4 ; Type & Length of sender ATM subnumber = 0 705 Length 1 ; Source IP address length 706 Length 2 ; Target IP address length 708 Operation code 709 0x10 = PROPOSE 710 0x11 = PROPOSE ACK 711 0x12 = PROPOSE NACK 713 VCID Type: VCID Type field as described later 714 VCID Length: Length of VCID field (Byte) 715 VCID : VCID field as described later 717 4.2 FANP Common Header 719 FANP control messages except for VCID notification messages(PROPOSE, 720 PROPOSE ACK,PROPOSE NACK) consist of a FANP common header and FANP 721 objects described in section 4.3 . 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Version |I| Op Code | Checksum | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Sender ID | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Receiver ID | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 / / 733 / Object / 734 / / 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Version : The protocol version of FANP. This protocol version is 2. 739 I Flag : 740 This flag is zero if this message is for the DC-Mode. 741 This flag is one if this message is for the IC-Mode[3]. 742 This flag is zero in HELLO,INIT,RECOGNIZE and KEEP_ALIVE messages. 744 Operation Code: 745 This field indicates the operation code of the message. 746 The value of operation code is as follows. 748 operation code = 1 : HELLO message 749 operation code = 2 : INIT message 750 operation code = 3 : RECOGNIZE message 751 operation code = 4 : KEEP_ALIVE message 752 operation code = 5 : ERROR message 753 operation code = 6 : NOTIFY message 754 operation code = 7 : NOTIFY ACK message 755 operation code = 8 : REMOVE_FLOW message 756 operation code = 9 : REMOVE_FLOW ACK message 757 operation code = 10 : REMOVE_ALL message 758 operation code = 11 : REMOVE_ALL ACK message 759 operation code = 12 : UPDATE message 760 (used by IC-mode) 761 operation code = 13 : UPDATE ACK message 762 (used by IC-mode) 764 Checksum 765 This field is the 16 bits checksum for the whole body of the 766 FANP message. The checksum algorithm is the same as that used 767 for the IP header. 769 Sender ID 770 The Local ID of the sender of the message. This field is zero 771 for HELLO messages. 773 Receiver ID 774 The Local ID of the receiver of the message. This field is zero 775 for HELLO and INIT messages. 777 4.3 FANP Objects 779 4.3.1 Object Header 781 The FANP object header format is as follows. 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Object Type | Object Flags | Object Length | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Object Type : The type of this object. 791 Object Flags : The flag of this object. The semantics of this field 792 depends on the object types. 794 Object Length : The length of the object (in bytes) includes the 795 object header. 797 4.3.2 Map Object 799 A format of MAP OBJECT, which maps VCID, FlowID and LLID, is as 800 follows. This object type is 1. 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 |Object Type = 1| Reserved | Object Length | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | VCID Type | FlowID Type | Error Code | LLID | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | VCID | 810 / / 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | FlowID | 813 / / 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 Object Type : Set to 1 for Map Object 817 Object Length : The length of the object (in bytes) includes the 818 object header. 820 VCID Type : The type of VCID. It is zero if no VCID field. 821 FlowID Type : The type of FlowID. It is zero if no FlowID field. 822 Error Code : If this message is ERROR message, the following 823 error code is put into this field. 824 Error Code = 1: unknown VCID Type 825 Error Code = 2: unknown VCID 826 Error Code = 3: unknown FlowID Type 827 Error Code = 4: unknown FlowID 828 Error Code = 5: resource unavailable 829 Error Code = 6: refuse as a matter of policy 830 Error Code = 7: hop count threshold exceeded 831 (used by IC-mode) 832 Error Code = 8: same FlowID received on different interface 833 (used by IC-mode) 834 Error Code = 9: unknown LLID 836 LLID : The Low Layer ID (LLID) field. If LLID isn't needed, 837 this field is zero. 838 VCID : The VCID field as described latter. 839 FlowID : The FlowID field as described latter. 841 4.3.2.1 VCID Field Format 843 VCID type value decides VCID field format. Currently, only type "1" 844 and "2" are defined. The VCID field format 1 is shown below. 846 VCID Type = 1: 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | ESI of upstream node | 852 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | | | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 855 | ID | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 ESI : IEEE 802 MAC address (ESI:End System Identifier [10]) 859 of the upstream node. 860 ID : A unique identifier allocated by the upstream node. 862 VCID Type = 2: Explicit ATM Label (4 bytes) 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 |Reservd| VPI | VCI | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 4.3.2.2 FlowID field 872 FlowID type value decides FlowID field format. Currently, FlowID 873 type "1", "2" and "3" are defined. The format is shown below. 875 FlowID Type = 1: 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Source IP address | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Destination IP address | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 Source IP address : source IP address of a flow 886 Destination IP address : destination IP address of a flow 888 FlowID Type = 2: 890 0 1 2 3 891 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 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Reserved | Protocol | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Source IP address | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Destination IP address | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Protocol ID : protocol ID of a flow 901 Source IP address : source IP address of a flow 902 Destination IP address : destination IP address of a flow 903 Source port : source port of a flow. If a flow doesn't 904 have it, this field is zero. 905 Destination port : destination port of a flow. If a flow 906 doesn't have it, this field is zero. 908 FlowID Type = 3: 910 0 1 2 3 911 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 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Destination IP address | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Destination network mask | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 Destination IP address : destination IP address of a flow 919 Destination network mask : netmask of a flow 921 4.3.3 Capability Object 923 This object is only used by FANPv2-ND. The value of this object type 924 is 2. Details are described in [4]. 926 4.3.4 VCID Range Object 928 This object is only used by FANPv2-ND. The value of this object type 929 is 3. Details are described in [4]. 931 4.3.5 Hop Count Object 933 This object is only used by IC-Mode. The value of this object type 934 is 4. Details are described in [3]. 936 4.3.6 Ingress Object 938 This object is only used by IC-Mode. The value of this object type 939 is 4. Details are described in [3]. 941 4.4 Examples of Message 943 ERROR,NOTIFY,NOTIFY_ACK,REMOVE_FLOW,REMOVE_FLOW ACK,REMOVE_ALL and 944 REMOVE_ALL ACK messages have a common header and one or more than 945 one map objects. 947 [ ....] 949 5. Security Considerations 950 Security issues are not discussed in this document. 952 6. Intellectual Property Considerations 954 Toshiba Corporation may seek patent or other intellectual property 955 protection for some or all of the aspects of the technology 956 discussed in this document. If any standards arising from this 957 document are or become protected by one or more patents assigned to 958 Toshiba Corporation, Toshiba intends to license them on reasonable 959 and non- discriminatory terms. 961 7. References 963 [1] Y. Katsube, et al., "Toshiba's Router Architecture Extensions for 964 ATM : Overview", RFC2098, Feb. 1997 966 [2] Y. Katsube, et al., "Cell Switch Router - Architecture and 967 Protocol Overview -", Internet Draft 968 draft-katusbe-csr-arch-00.txt(work in progress), Dec. 1997 970 [3] Y. Ohba, et al., "FANP Version 2 - Ingress Control Mode", 971 Internet Draft draft-ohba-csr-fanpv2-icmode-00.txt(work in 972 progress), Dec. 1997 974 [4] K. Nagami, et al., "FANP Version 2 - Neighbor Discovery", 975 Internet Draft draft-nagami-csr-fanpv2-nd-00.txt(work in 976 progress), Dec. 1997 978 [5] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation 979 Layer 5", RFC1483, July 1993. 981 [6] M. Laubach, "Classical IP and ARP over ATM", RFC1577, Oct. 1993 983 [7] R. Braden, et al., "Resource ReSerVation Protocol (RSVP)", 984 RFC2205, Sep. 1997 986 [8] N. Demizu, et al., "VCID: Virtual Connection Identifier", 988 [9] N. Demizu, et al., "VC Pool", Internet Draft 989 draft-demizu-mpls-vcpool-00.txt, Oct. 1997 991 [10] "UNI Specification Version 3.1", ATM Forum, Sep. 1994 993 8. Authors' Addresses 994 Ken-ichi Nagami 995 Research and Development Center, Toshiba 996 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 997 Japan 998 Phone : +81-44-549-2238 999 EMail : nagami@isl.rdc.toshiba.co.jp 1001 Yasuhiro Katsube 1002 Research and Development Center, Toshiba 1003 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 1004 Japan 1005 Phone : +81-44-549-2238 1006 EMail : katsube@isl.rdc.toshiba.co.jp 1008 Shigeo Matsuzawa 1009 Research and Development Center, Toshiba 1010 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 1011 Japan 1012 Phone : +81-44-549-2238 1013 EMail : shigeom@isl.rdc.toshiba.co.jp 1015 Akiyoshi Mogi 1016 Research and Development Center, Toshiba 1017 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 1018 Japan 1019 Phone : +81-44-549-2238 1020 EMail : mogi@isl.rdc.toshiba.co.jp 1022 Koutarou Ise 1023 Research and Development Center, Toshiba 1024 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 1025 Japan 1026 Phone : +81-44-549-2238 1027 EMail : ise@isl.rdc.toshiba.co.jp 1029 Appendix A: How to construct a default-VC 1031 A default-VC in the case of ATM is as follows. 1033 SVC : created using RFC1577[6] 1034 PVC : set up by manual configuration 1035 VP : VCI = 32 is reserved for the default-VC 1036 Point-to-Point : VPI = 0, VCI = 32 is reserved for the default-VC 1038 Appendix B: Packet Encapsulation 1039 In the case of ATM, the encapsulation over default-VCs and 1040 dedicated-VCs is LLC encapsulation for routed non-ISO protocols 1041 defined by RFC1483 [5]. 1043 Appendix C: Default Timer value / Default resend times 1045 Timer: 1047 HELLO Timer : 60 sec 1048 Resend Timer(INIT,RECOGNIZE,KEEP ALIVE) : 30 sec 1049 Resend Timer(others): 2,4,8,16,32,64,64,64,.... sec 1051 Resend Times: 1052 Resend PROPOSE : 3 times 1053 Resend NOTIFY : 3 times