Internet Draft Internet-Draft Yasuhiro Katsube Ken-ichi Nagami Yoshihiro Ohba Shigeo Matsuzawa Hiroshi Esaki (Toshiba Corporation) December 1997 Cell Switch Router - Architecture and Protocol Overview - <draft-katsube-csr-arch-00.txt> Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memorandum describes an internetworking architecture of Cell Switch Router (CSR) and related control protocol overview. Cell Switch Router is an ATM-based label switching router that can provide ATM cut-through paths for packet flows with various levels of granularity while retaining current router-based internetworking architecture. The proposed architecture is able to provide the cut-through path in response to the creation of IP forwarding entry (topology-driven), the arrival of data packets (traffic-driven), and the reception of control packets such as RSVP (request-driven). One important feature that is provided by the proposed architecture is interoperability with the emerging ATM network platform, specified by the ATM Forum and/or ITU-T, which provides PVC (Permanent Virtual Channel), VP (Virtual Path), or SVC (Switched Virtual Channel) services. Katsube, et al. Expires June 1998 [Page 1] Internet Draft CSR - Architecture and Protocol - December 1997 Table of Contents 1. Introduction ................................................. 2 2. Internetworking Architecture Based on Cell Switch Router ..... 3 2.1 Architectural Overview ...................................... 3 2.2 Triggers for Cut-Through Path Establishment ................. 5 2.3 Interoperation with Standard ATM Network Platform ........... 6 3. Cell Switch Router Control Mechanism ......................... 8 3.1 Neighbor Discovery .......................................... 8 3.2 Two Modes of Protocol Operation ............................. 8 3.2.1 Distributed Control Mode (DC-mode) ........................ 8 3.2.1.1 Operational Overview .................................... 8 3.2.1.2 Examples of DC-mode Operation ........................... 9 3.2.2 Ingress Control Mode (IC-mode) ............................10 3.2.2.1 Operational Overview ....................................10 3.2.2.2 Examples of IC-mode Operation ...........................12 3.3 Operations Dependent on the Type of Underlying ATM Networks..12 3.3.1 PVC-based ATM network .....................................13 3.3.2 SVC-based ATM network .....................................13 4. Security Considerations ......................................14 5. Intellectual Property Rights Considerations ..................14 6. References ...................................................15 7. Authors' Addresses ...........................................15 1. Introduction The Internet is growing in both size and traffic volume. In addition, emerging applications may require specific bandwidth and quality of services (QoSs) in addition to best effort. Such changes require conventional routers with more sophisticated processing capability, which tends to raise the cost of routers, and accelerate investigations of a new internetworking architecture that relies on powerful datalink switching capabilities. The proposed internetworking architecture is composed of i)CSRs that have ATM label switching capability as well as conventional layer 3 packet forwarding, ii)edge nodes that are located at boundaries between the proposed network and legacy networks (e.g., ATM networks with legacy routers, non-ATM networks), and iii)end hosts that are capable of speaking with the CSRs. Direct ATM level connectivities from ingress edge nodes (or hosts) to egress edge nodes (or hosts) are provided via intermediate CSRs on the path with the ATM label switching capability inside (we refer to this ATM level connectivity as an "ATM cut-through path"). The cut-through path is controlled by each of the CSRs on the path as Katsube, et al. Expires June 1998 [Page 2] Internet Draft CSR - Architecture and Protocol - December 1997 well as by ingress/egress edge routers or hosts, which keeps conventional hop-by-hop control discipline for managing dynamic layer 3 state for unicast and multicast routing, RSVP, and so on. The proposed internetworking architecture is designed so as to be able to operate over standard ATM networks which are compliant with ATM Forum and/or ITU-T that support PVC (Permanent Virtual Channel), VP (Virtual Path), or SVC (Switched Virtual Channel) services, as well as over point-to- point links. 2. Internetworking Architecture Based on Cell Switch Router 2.1 Architectural Overview Cell Switch Router(CSR) is a key network element of the proposed internetworking architecture[13]. It is interconnected with ATM networks through ATM UNI interface[1] and provides cell switching functionality in addition to conventional IP packet forwarding. It is able to concatenate incoming and outgoing ATM VCs at the ATM layer, bypassing packet header processing. By carrying out such ATM VC concatenations at multiple CSRs consecutively, ATM level cut-through paths composed of multiple VCs, each of which connects neighboring CSRs (or CSR and hosts/edge routers), can be provided. Two different kinds of VCs for transmitting packets are defined between neighboring CSRs or between CSR and hosts/edge routers. 1) Default-VC : a general-purpose VC used by any communications that select conventional hop-by-hop IP forwarding paths. All incoming cells received from this VC are assembled into IP packets and handled based on their IP headers. 2) Dedicated-VC : used by a specific packet flow, which is specified by, e.g., {dst.IP address, src.IP address} or {dst.IP address, src.IP address, protocol, dst.port, src.port}. It can be concatenated with other Dedicated-VC(s) that accommodate the same packet flow as itself, and can constitute an ATM cut-through path for those packet flows. The route for a cut-through path follows IP routing information in each CSR. As shown in Figure 1, packets from an ingress edge router (or source host) X.1 to an egress edge router (or destination host) Z.1 are transferred over the route X.1 --> CSR1 --> CSR2 --> Z.1 regardless of whether the communication is on a hop-by-hop IP forwarding basis or cut-through path basis. An example of the IP packet transmission mechanism is as follows. - The ingress edge X.1 checks an identifier of each IP packet flow, Katsube, et al. Expires June 1998 [Page 3] Internet Draft CSR - Architecture and Protocol - December 1997 which may be the "destination IP address (or prefix)", "source/destination IP address (prefix) pair", "source/destination IP address and port" or "source IP address and group address". Based on such identifiers, it determines over which VC the packet should be transmitted. - The CSR1 and CSR2 check the VPI/VCI value of each incoming cell. When the mapping from the incoming interface/VPI/VCI to outgoing interface/VPI/VCI (which may be plural in the case of multicast) is found in an ATM forwarding table, it is directly forwarded to the specified interface(s) with the new VPI/VCI value through an ATM switch module. When the mapping is not found in the ATM forwarding table (or the table shows an IP processing module as an output interface), the cell is transmitted to an IP processing module and assembled into an IP packet and then forwarded to an appropriate outgoing interface/VPI/VCI based on the header of the packet. IP subnet X IP subnet Y IP subnet Z <---------------------> <-----------------> <---------------------> +-------+ Default +-------+ Default +-------+ Default +-------+ | | -VC | CSR 1 | -VC | CSR 2 | -VC | | | Host +=============+ +===============+ +=============+ Host | | or +-------------+++++---------------+++++-------------+ or | | Edge +-------------+++++---------------+++++-------------+ Edge | | X.1 +-------------+++++---------------+++++-------------+ Z.1 | | |Dedicated | | Dedicated | |Dedicated | | +-------+ -VCs +-------+ -VCs +-------+ -VCs +-------+ <---------------------------------------------------> Cut-through Path Figure 1 Internetworking Architecture based on CSR A CSR becomes the termination point (egress edge) of a cut-through path when it is an edge of the ATM cloud regarding the end-to-end path, it is an edge of the CSR-capable router cloud regarding the end-to-end path, or it cannot create a Dedicated-VC toward the downstream neighbor for the end-to-end path for some reason. The CSR-capable router is required to understand a control protocol that exchanges mapping information between each dedicated-VC and a specific packet flow that will be transmitted over the VC. Note that the egress edge of the cut-through path can also perform the cut-through forwarding which bypasses IP processing. Since the Katsube, et al. Expires June 1998 [Page 4] Internet Draft CSR - Architecture and Protocol - December 1997 egress edge router can memorize the association between each of the cut-through paths it terminates and the specific packet flow which is transmitted over the path by using the control protocol described in section 3, it can obtain the same information as by referring to the IP header, i.e., source IP address and destination IP address etc., by referring to the identifier of the incoming dedicated-VC (VPI/VCI). That means that the egress edge router can forward packets received from the dedicated-VC to a proper downstream neighbor without referring to their IP header even though the corresponding outgoing dedicated-VC does not exist. In the rest of the document, all the CSR-capable devices including CSR, edge router, and end host will be referred to as "CSR" for simplicity unless there is a need to distinguish among them. 2.2 Triggers for Cut-Through Path Establishment CSR is able to initiate cut-through path establishment in response to the creation of IP forwarding table entries (topology-driven), the arrival of data packets (traffic-driven), and the reception of control traffic such as RSVP resource reservation request (request- driven)[2]. This subsection describes three triggers for cut-through path establishment by CSRs, together with possible granularity of packet flows (conditions that specify the packet flow conveyed over the cut-through path) in each of the cases. 1) Topology-driven path establishment : In topology-driven, the cut-through path establishment procedure is initiated when a new IP level forwarding table entry is created at a CSR. The cut-through path can naturally accommodate aggregated packet flow which is specified by, e.g., {ingress edge router, dest.prefix}, {ingress edge router, egress edge router}, {*, dest.prefix}, or {*, egress edge router}. The latter two may require ATM switches to provide flow merging capability while avoiding AAL5 frame interleaving. Note that the topology-driven aggregated paths should not be extended beyond the points where the processing for individual end-end flows (e.g., packet filtering or QoS differentiation) should be carried out but be terminated at those points. 2) Traffic-driven path establishment : Katsube, et al. Expires June 1998 [Page 5] Internet Draft CSR - Architecture and Protocol - December 1997 In traffic-driven, the path setup procedure is initiated when the CSR determines that it is worth providing the path for a specific packet flow, e.g., * transmission of a packet with specific upper layer protocols defined by the port ID of TCP/UDP * transmission of TCP SYN packet * transmission of a packet with specific source/destination IP addresses * transmission of more than a certain amount of packets in a predetermined period Granularity of the packet flow for the traffic-driven path could be {src.IP_addr, dest.IP_addr} as a default, although aggregated cut-through paths specified by, e.g., {ingress edge router, dest.prefix}, can also be established with traffic-driven. 3) Request-driven path establishment : In request-driven, the path setup procedure is initiated when the CSR receives some control messages (requests) which are not specific to CSR network but affect the cut-through operation of the CSR. An example of such a control message is RSVP Reservation (Resv) request [3] which requests the CSR to provide specific quality of services with regard to the packet forwarding. The CSR which has received a Resv message prepares a dedicated-VC for the requested RSVP flow. Granularity of the packet flow for the request(RSVP)-driven path could be {src.IP_addr/port, dest.IP_addr/port} as a default although {src.IP_addr, dest.IP_addr} may be allowable in some cases. Reservation styles shared by multiple senders (Wild Card style and Shared Explicit style) should be supported by the cut-through paths dedicated to individual senders like a Fixed Filter style for simplicity. 2.3 Interoperation with Standard ATM Network Platform Interconnecting multiple CSRs through point-to-point (p-p) links such as SONET link is a straightforward configuration that is easy to implement. In addition, CSRs are designed to be interconnected with each other over the emerging ATM network platform that is compliant with the ATM Forum or ITU-T standard UNI. That enables the ATM network platform to be utilized for Internet/Intranet services as well as other services such as telephony and native ATM services. In addition, Internet/Intranet services based on CSRs can coexist with and operate over classical IP over ATM[4] networks, which provide intra-subnet communications. Katsube, et al. Expires June 1998 [Page 6] Internet Draft CSR - Architecture and Protocol - December 1997 CSR operations over three types of ATM networks should be taken into account; 1) VP-based ATM network : provides a VP as a tunnel between neighboring CSRs and picks up an unused VCI in the VP each time a dedicated-VC is needed. 2) PVC-based ATM network : provides a number of PVCs between neighboring CSRs at an initialization phase and picks up one of them each time a dedicated-VC is needed. 3) SVC-based ATM network : provides an SVC between neighboring CSRs through ATM signaling each time a dedicated-VC is needed. In the case 3), it is possible that a number of SVCs are set up in advance through ATM signaling and are registered as a stock, which we call "VC pool" approach[5]. Then one of them can be picked up each time a dedicated-VC is needed, which is a similar approach to the PVC case. Although the necessary VC resources with the VC pool approach will be larger than the on-demand SVC setup, the VC pool approach can decrease latency for setting up the cut-through path as there is no delay for ATM signaling. In addition, the VC pool approach can reduce the processing burden for setting up or releasing SVCs when the number of surplus VCs between neighboring CSRs is controlled between a predetermined lower bound and an upper bound. That is, an additional SVC is set up only when the number of surplus SVCs becomes smaller than a predetermined lower bound, whereas one of the surplus SVCs is released only when it becomes larger than a predetermined upper bound. Whether the "on-demand setup approach" or "VC pool approach" should be applied is a matter of local decision in each network, taking cost and the system responsiveness into account. ATM networks can be utilized either as logical point-to-point links in which IP addresses are assigned to a CSR for each neighbor CSR, or as a multi-access (NBMA) link in which a single IP address is assigned to a CSR for each logical IP subnet (LIS) composed of several neighbor CSRs. When CSRs are operated over multi-access ATM LIS environment, point-to-point (p-p) dedicated-VCs or point-to-multipoint (p-mp) dedicated-VCs toward its next-hop(s) are utilized by each CSR to provide intra-subnet connectivity. ATMARP server[4] or MARS [6] will be used when the CSR does not know an ATM address(es) of its neighbor CSR(s) or edge node(s). Note that this does not exclude the use of other methods for unicast/multicast ATM address resolution. Katsube, et al. Expires June 1998 [Page 7] Internet Draft CSR - Architecture and Protocol - December 1997 3. Cell Switch Router Control Mechanism This section presents an overview of "FANP (Flow Attribute Notification Protocol)", that is a protocol between neighboring nodes (CSRs, edge routers, and end hosts) in order to establish, maintain, and tear down the cut-through paths. There are several changes in an updated version of FANP (FANP version 2) from FANP v1[7]. They are i)provision of a neighbor discovery protocol[8] that enables CSRs to recognize their neighbors, ii)adoption of two modes of cut-through path control mechanism; Distributed Control mode (DC-mode)[9] and Ingress Control mode (IC-mode)[10], and iii)support of interoperability with variety of ATM network platforms. Each of them will be explained in this section. 3.1 Neighbor Discovery The neighbor discovery (ND) is used for recognizing neighbors that understand FANPv2, obtaining FANPv2 protocol attributes of the neighbors, and checking whether consistent states are maintained by the neighboring CSRs. A FANP-capable node recognizes that FANP is running on a neighbor node provided it periodically receives ND messages from the neighbor. The ND procedure takes different actions depending on whether the underlying network interface is point-to-point or multi-access. Detailed procedure for each type of interface is described in [8]. 3.2 Two Modes of Protocol Operation CSR supports two modes of control operation; Distributed Control mode (DC-mode)[9] and Ingress Control mode (IC-mode)[10]. An overview and examples of application of each operation mode are described below. Which mode of operation each control message belongs to is distinguished by a bit in the common header of the FANP message. 3.2.1 Distributed Control Mode (DC-mode) 3.2.1.1 Operational overview In the DC-mode, the cut-through path establishment procedure for a packet flow is initiated at individual CSRs on its path in a distributed manner. Each of them transmits control messages to its downstream neighbor in order to notify the mapping relationship between the packet flow and the outgoing dedicated-VC that will Katsube, et al. Expires June 1998 [Page 8] Internet Draft CSR - Architecture and Protocol - December 1997 convey the flow. The downstream CSR that has received the control message from its upstream neighbor checks the validity of the message, memorizes the received mapping information at its incoming interface, and transmits an acknowledgment to the upstream neighbor. This message exchange with an upstream neighbor at the CSR does not initiate the exchange of any control messages with its downstream neighbor in the DC-mode. A control message exchange for a flow between a pair of neighboring CSRs is initiated and carried out independently from the message exchange for the same flow between any other pair of CSRs. As a result of control message exchanges performed at individual pair of CSRs, a CSR realizes that both the incoming and the outgoing dedicated-VC are associated with the same packet flow, and then begins cut-through forwarding. The release of the cut-through path is also initiated at individual CSRs on the path. A CSR that has detected the trigger to release the cut-through path transmits control messages to its downstream neighbor to cancel the association between the packet flow and the outgoing dedicated-VC that conveys the flow. The reception of the control message at a CSR from the upstream neighbor does not initiate the transmission of the control message to the downstream neighbor. As no information regarding the cut-through path with edge-to-edge importance can be obtained in the DC-mode, an ingress edge knows neither the number of hops for the path nor the constitution of the loop in the path. It is easy to change the configuration of cut-through paths according to dynamic changes in the router state, e.g., unicast routing, multicast group membership/routing, and RSVP reservation state. The common rule with regard to the trigger selection for the cut- through path establishment (the condition to initiate the cut-through establishment) and release, and the granularity level of the packet flow should be configured to individual CSRs in a domain, since no such information is conveyed hop-by-hop by the control messages in the DC-mode. 3.2.1.2 Examples of DC-mode Operation The DC-mode operation can be adopted for establishing the traffic- driven unicast cut-through paths. Individual CSRs on the path can recognize the flow of the layer 3 level end-to-end granularity by referring to the data packets (e.g., {src.IP_addr., dest.IP_addr}). They can also commonly recognize the aggregated flow of {src.IP_addr., dest.prefix} granularity individually as long as they have the IP forwarding table entry with the same CIDR prefix Katsube, et al. Expires June 1998 [Page 9] Internet Draft CSR - Architecture and Protocol - December 1997 given by the routing protocol. Control of multicast cut-through paths is suitable for the DC-mode operation as the management of group membership, which may change frequently, is carried out by individual CSRs on the distribution tree. Each CSR is able to add a new leaf to or delete a leaf from the active cut-through path in response to detection of join or leave of a group member at corresponding interfaces. The granularity of {src.IP_addr., multicast group addr.} is straightforward although the shared tree defined by, e.g., {Rendezveus Point, multicast group addr.} is also possible. Concrete triggers for cut-through establishment or release may depend on the routing protocol deployed and implementation. Arrival of the data traffic, creation of the multicast forwarding cache, or reception of PIM Join messages can be the trigger. Control of cut-through paths in response to the RSVP reservation state (request-driven) at individual CSRs on the path will also be appropriate for the DC-mode operation. Reception of the reservation (Resv) messages at a CSR from its downstream neighbor initiates the control message exchange, which notifies the mapping relationship between the flow corresponding to the RSVP session and the dedicated-VC that will convey the flow, with the downstream neighbor. Then the CSR transmits the Resv message further upstream. Here we assume the use of current standard RSVP message format[3] with no additional object defined for this purpose. 3.2.2 Ingress Control Mode (IC-mode) 3.2.2.1 Operational overview In the IC-mode, the cut-through path establishment procedure for a packet flow is initiated by a CSR that is hoping to become an ingress edge of the cut-through path. The ingress edge transmits control messages to its downstream neighbor in order to notify the mapping relationship between the packet flow and the Dedicated-VC that will convey the flow. The message is composed of i)information that identifies the flow, ii)information that identifies the dedicated-VC, iii)ingress information that is uniquely created by the ingress node for the cut-through path, and iv)a hop count that is set to one by the ingress edge. The last two information elements are specific to the IC-mode operation, which provides a capability to prevent the creation of a potential loop of the cut-through path. The CSR that has received the messages for the notification of the mapping relationship from the upstream neighbor checks the validity of the message, and memorizes the received mapping information at its incoming interface. Then the CSR reconstructs and transmits Katsube, et al. Expires June 1998 [Page 10] Internet Draft CSR - Architecture and Protocol - December 1997 control messages further downstream along the path of the flow to notify the mapping relationship between the flow notified by the upstream neighbor and a dedicated-VC that will convey the flow. The same procedure is performed at every CSR along the path of the flow until the notification message reaches the CSR that cannot extend the cut-through path any more (e.g., an egress edge of the CSR cloud). The CSR that becomes the egress endpoint of the cut-through path returns the acknowledgment message to its upstream neighbor, which is forwarded hop-by-hop toward the ingress edge (the ingress point of the cut-through path). This ingress to egress and egress to ingress message forwarding facilitates association of related information about the cut-through path. As mentioned above, the control message that notifies the mapping relationship contains "a hop count from the ingress edge" and "an ingress information that is determined by the ingress edge for the cut-through path it originates". The hop count value is initially set to one by the ingress edge and is incremented by one at each of the CSRs along the cut-through path. When a CSR recognizes that the hop-count value in the notification message reaches a predetermined threshold, it determines that there is a potential loop in the cut-through path. The CSR also determines that there is a potential loop when it has received a notification message that contains the packet flow identifier and ingress information, both of which are the same as those already registered, but contains the dedicated-VC identifier that is not the same as has been registered. The CSR that detects the potential loop stops creation of the cut-through path toward its downstream, and returns an error message to the upstream neighbor. The ingress edge is able to know the number of hops from itself to the egress endpoint of the cut-through path by referring to the acknowledgement messages initiated by the egress node. The hop-count in the acknowledgement message transmitted by the egress node is set to one and incremented by one at each of the CSRs along the reverse path of the cut-through. The ingress edge may decrement the TTL value of the received packet by the number of hops it learned, or may decrement that by one. In the IC-mode, the CSR that has failed to extend the cut-through path toward its downstream for specific reasons retries path establishment after some specified intervals. When the CSR has succeeded in extending the cut-through path by the retry procedure, the number of hops from the CSR to the egress edge may change, which means that the number of hops from the ingress edge to the egress edge may also change. The CSR that has succeeded in extending the cut-through path transmits a message that notifies an updated hop-count from the egress edge toward the ingress edge. Katsube, et al. Expires June 1998 [Page 11] Internet Draft CSR - Architecture and Protocol - December 1997 3.2.2.2 Examples of IC-mode Operation The IC-mode operation can be adopted for establishing the unicast cut-through paths with aggregated packet flows as well as flows with fine granularity level. Examples of the flow granularity are {ingress edge's IP_addr., dest.prefix} and {ingress edge's IP_addr., egress edge's IP_addr.}. The trigger to establish the cut-through path may be either topology-driven or traffic-driven. Irrespective of the flow granularity and cut-through establishment trigger, the notification message is processed at each CSR along the path and transmitted hop-by-hop until it arrives at an egress edge. 3.3 Operations Dependent on the Type of Underlying ATM Networks As described in 2.3, CSRs should be interconnected over the following four types of datalink: (a) Point-to-point link that interconnects neighboring CSRs directly (b) VP-based ATM network that provides logical point-to-point link (c) PVC-based ATM network (d) SVC-based ATM network The core procedure of the FANPv2 control mechanism performed by the neighboring CSRs is a notification of the association between a packet flow and a dedicated-VC that will convey the packet flow, and an acknowledgment to the notification, which we call "flow notification procedure". The use of the VPI/VCI value as an identifier of a dedicated-VC in the flow notification procedure would suffice in the case (a) and (b). It, however, does not work when CSRs are interconnected over an ATM network that provides PVC or SVC services. Since VPI/VCI values at the origination point (outgoing interface of the upstream CSR) and the termination point (incoming interface of the downstream CSR) of a VC are not the same when there are standard ATM switches in between, the VPI/VCI value cannot be used as an identifier of a dedicated-VC in the flow notification procedure. A "VCID (Virtual Connection IDentifier)"[11] is introduced instead, which can be uniquely identified by the neighboring CSRs to indicate a dedicated-VC in the flow notification procedure. In the case of (c)PVC-based ATM network and (d)SVC-based ATM network, a procedure to assign the VCID to each dedicated-VC, which we call "VCID notification procedure", should be performed before the flow notification procedure. Note that in the case of (a)the p-p link and (b)the VP-based ATM network, no explicit VCID notification procedure is needed since the VPI/VCI (or just the VCI) value in the cell header can be used as the VCID in those cases. Katsube, et al. Expires June 1998 [Page 12] Internet Draft CSR - Architecture and Protocol - December 1997 The concrete procedure for the VCID notification differs depending on the type of the underlying ATM network: PVC-based ATM or SVC-based ATM[12]. 3.3.1 PVC-based ATM network An upstream CSR transmits a message that includes a VCID value over the PVC itself (in-band notification). The VCID value is determined by the upstream CSR and should be unique to the pair of CSRs. When the downstream CSR transmits the acknowledgment of the above in-band message to the upstream CSR, the upstream and downstream CSRs can share the same identifier VCID for the PVC. This in-band VCID notification procedure can be carried out either immediately after the PVC setup or at the time when one of PVCs is picked up for a specific cut-through path in response to cut-through establishment trigger. 3.3.2 SVC-based ATM network There are two ways for the VCID notification in the case of the SVC- based ATM network. One is the in-band notification described above; an upstream CSR conveys the VCID value over the SVC that is being utilized as a dedicated-VC. This would be adopted when the other way described below is not applicable. An alternative way for the VCID notification is the use of an Information Element (IE) with end-to-end significance in a SETUP message of ATM signaling. When an upstream CSR transmits an ATM SVC SETUP message toward its downstream neighbor, it determines a unique ID value as the VCID and includes it in the IE that is transparently conveyed by the ATM switches in between. After that, the upstream CSR is able to perform the flow notification procedure by using the above VCID as an identifier of the dedicated-VC. A "user specified layer 3 protocol information field" of the BLLI (Broadband Low Layer Information) IE is the most appropriate field for this purpose. An issue in this method is that the user specified layer 3 protocol information field of the BLLI IE is given just 7 bits, which can identify only 128 VCs simultaneously between neighboring CSRs. In order to resolve the limitation of the 7-bit BLLI IE, an additional message exchange that notifies the mapping between the 7-bit number conveyed in the BLLI IE (a temporal VCID) and an actual VCID, which is determined uniquely by the upstream CSR and is given enough bit space, is carried out at the VCID notification phase. Namely, after the upstream CSR has set up an SVC with the 7-bit temporal ID value, it transmits a control message that replaces the temporal ID with the VCID. At this stage, the temporal ID value is released and could be reused by the other SVC. The flow notification Katsube, et al. Expires June 1998 [Page 13] Internet Draft CSR - Architecture and Protocol - December 1997 procedure will be performed by exchanging the message that conveys the association between the VCID and a specific packet flow. The procedure is: 1) SVC SETUP with temporal ID in the BLLI IE 2) VCID notification : message exchange that replaces "temporal ID" with "VCID" (temporal ID is released for the other SVCs) 3) Flow notification : message exchange that notifies association between the "VCID" and a specific "packet flow" In the case that the "VC pool" approach described in 2.3 is applied, the above steps 1) and 2) are carried out when preparing a dedicated-VC for future use, and the step 3) is carried out when establishing a cut-through path. In the case that the "on-demand setup" approach described in 2.3 is applied, it is possible to perform the above two steps 2) and 3) by a single message exchange. By making the flow notification message convey the "temporal ID", "VCID", and "packet flow", the VCID notification step can be merged into the flow notification step. The procedure comes to: 1) SVC SETUP with temporal ID in the BLLI IE 2) Flow notification : message exchange that notifies association between the "temporal ID", "VCID" and a specific "packet flow" (temporal ID is released for the other SVCs) The detailed procedure for the cut-through establishment and release in individual cases is described in [9]. 4. Security Considerations Security issues are not discussed in this document. 5. Intellectual Property Considerations Toshiba Corporation may seek patent or other intellectual property protection for some or all of the aspects of the technology discussed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Toshiba Corporation, Toshiba intends to license them on reasonable and non- discriminatory terms. 6. References [1] The ATM Forum, "ATM User-Network Interface Specification, v3.1", Katsube, et al. Expires June 1998 [Page 14] Internet Draft CSR - Architecture and Protocol - December 1997 Sept. 1994. [2] R. Callon, et al., "A Framework of Multiprotocol Label Switching", IETF Internet-Draft (work in progress), draft-ietf-mpls-framework- 01.txt, July 1997. [3] R. Braden, et al., "Resource ReSerVation Protocol (RSVP), Version 1 Functional Specification", IETF RFC2205, Sept. 1997. [4] M. Laubach, "Classical IP and ARP over ATM", IETF RFC1577, Oct. 1993. [5] N. Demizu, et al., "VC Pool", IETF Internet-Draft (work in progress), draft-demizu-mpls-vcpool-00.txt, Oct. 1997. [6] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM Networks", IETF RFC2022, Nov. 1996 [7] K. Nagami, et al., "Toshiba's Flow Attribute Notification Protocol (FANP) Specification", IETF RFC2129, April 1997. [8] K. Nagami, et al., "Flow Attribute Notification Protocol Version 2 (FANPv2) Neighbor Discovery", IETF Internet-Draft (work in progress), draft-nagami-fanpv2-nd-00.txt, Dec. 1997 [9] K. Nagami, et al., "Flow Attribute Notification Protocol Version 2 (FANPv2) Distributed Control Mode", IETF Internet- Draft (work in progress), draft-nagami-csr-fanpv2-dcmode-00.txt, Dec. 1997. [10] Y. Ohba, et al., "Flow Attribute Notification Protocol Version 2 (FANPv2) Ingress Control Mode", IETF Internet-Draft (work in progress), draft-ohba-csr-fanpv2-icmode-00.txt, Dec. 1997. [11] N. Demizu, et al., "VC-ID: Virtual Connection Identifier", IETF Internet-Draft (work in progress), draft-demizu-mpls-vcid-01.txt, Oct. 1997. [12] N. Demizu, et al., "ATM SVC Support for ATM-LSRs", IETF Internet- Draft (work in progress), draft-demizu-mpls-atm-svc-00.txt, Oct. 1997. [13] Y. Katsube, et al., "Toshiba's Router Architecture Extensions for ATM : Overview", IETF RFC2098, Feb. 1997. 7. Authors' Addresses Yasuhiro Katsube Research and Development Center, Toshiba Corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 E-mail : katsube@isl.rdc.toshiba.co.jp Ken-ichi Nagami Research and Development Center, Toshiba Corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 E-mail : nagami@isl.rdc.toshiba.co.jp Katsube, et al. Expires June 1998 [Page 15] Internet Draft CSR - Architecture and Protocol - December 1997 Yoshihiro Ohba Research and Development Center, Toshiba Corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 E-mail : ohba@csl.rdc.toshiba.co.jp Shigeo Matsuzawa Research and Development Center, Toshiba Corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 E-mail : shigeom@isl.rdc.toshiba.co.jp Hiroshi Esaki Computer and Network Division, Toshiba Corporation 1-1-1 Shibaura, Minato-ku, 105-01, Japan Phone : +81-3-3457-2563 E-mail: hiroshi@isl.rdc.toshiba.co.jp Katsube, et al. Expires June 1998 [Page 16]