Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 Internet Engineering Task Force L. Westberg INTERNET-DRAFT G. Karagiannis Expires November 2002 D. Partain V. Rexhepi Ericsson May 2002 Framework for Edge-to-Edge NSIS Signaling draft-westberg-nsis-edge-edge-framework-00.txt Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Westberg, et al. Expires November 2002 [Page 1] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 Abstract Real-time applications impose very strict requirements on the underlying transmission network that requires a high level of quality of service (QoS). This level of QoS can only be achieved by means of QoS management on an end-to-end basis (i.e., end user to end user), from application to application, potentially across many domains, as the current Internet is a concatenation of many domains, usually managed by different QoS administrators (operators). The requirement for end-to-end QoS management does not necessarily mean that a single resource reservation protocol must be applied end- to-end. In fact it is most likely that the end-to-end QoS management architecture will consist of many interoperable and concatenated QoS management architectures rather than one global end-to-end QoS infrastructure. Usually a network consists of three network parts, i.e., a host to first hop router, access network and the backbone of the network. Each of these three network parts imposes different requirements on the provided QoS solution. This draft describes a framework for NSIS QoS signaling in edge to edge networks. The main goal is to provide a skeleton for lightweight edge to edge NSIS signaling in a network. This skeleton would be used as input to the NSIS "Framework signaling architecture". Even though designed for edge-to-edge signaling the applicability of this framework is not to be limited only to signaling between the edges of a network, but it can be extended in other signaling scenarios as well, such as end host - to - end host signaling. The QoS protocol that will be applied in an edge to edge network is denoted as edge-to-edge NSIS protocol. Westberg, et al. Expires November 2002 [Page 2] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 Table of Contents 1 Terminology .................................................. 4 2 Introduction and Motivation .................................. 4 3 Framework for Edge-to-Edge NSIS signaling .................... 6 3.1 Framework for Edge-to-Edge NSIS Signaling - Design Objec­ tives ..................................................... 7 3.2 Framework for Edge-to-Edge NSIS Signaling - Design Struc­ ture ...................................................... 9 3.2.1 NSIS interior-interior (II-Q) Component Features ......... 11 3.2.2 NSIS BN<->BN (BB-Q) Component Features ................... 11 3.2.3 NSIS Host<->BN (HB-Q) Components Features ................ 12 4 Edge-to Edge QoS NSIS Protocol ............................... 12 5 Edge-to-Edge NSIS signaling framework operation .............. 14 6 Conclusion ................................................... 14 7 Appendix A: Examples of Edge-to-Edge NSIS Signaling Mes­ sages ..................................................... 14 7.1 NSIS BN<->BN (BB-Q) Signaling Messages ..................... 14 7.2 NSIS Interior <-> Interior (II-Q) Signaling Messages ....... 15 8 Appendix B: Examples of Edge-to-Edge NSIS signaling frame­ work operation ............................................ 16 8.1 Normal Operation for Unidirectional Reservation ............ 17 8.2 Fault handling for unidirectional reservation .............. 21 8.3 Normal Operation for bidirectional (successful) reserva­ tion ...................................................... 23 9 Authors' Address ............................................. 26 Westberg, et al. Expires November 2002 [Page 3] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 1. Terminology - End-to-End QoS QoS management applied in all the domains from end-host to end-host. - Edge-to-Edge network Network wherein the QoS provisioning is co-ordinated by a single administrator (or operator). This is a single QoS administrative domain. - Edge Node The router boundaries of a single QoS administrative domain. - Interior Node Routers inside a single domain, which are not edge nodes. - Boundary Node A "box" which represents an endpoint of the local QoS domain and it is the interworking point between the end-to-end QoS and local QoS mechanism. This could be a router, BTS, BSC/RNC, media gateway, etc. 2. Introduction and Motivation The real time application requirements can only be satisfied by means of QoS management mechanisms that will have to be applied end-to-end from one host to the other. When considering the variety of applications, network access types, the underlying network technologies (wired and wireless), management policies and administration of the domains, etc, having a single QoS management scheme applied end-to-end is not feasible in all networking scenarios. For example, what might be a good solution for a wired network is not a good solution for networks with frequent mobility requirements. Usually a network consists of three network parts, i.e., a host to first hop router, access network, and the backbone of the network. Each of these three network parts imposes different requirements on the provided QoS solution. Westberg, et al. Expires November 2002 [Page 4] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 Typically an end-to-end QoS management architecture consists of many interoperable and concatenated QoS management architectures. Each QoS domain is responsible for taking its own decisions in its own domain- specific ways. An example is shown in Figure 1, where the end-to-end QoS management architecture consists of two concatenated QoS domains. This QoS architecture uses different types of interfaces: * interior <-> interior interface: provides basic QoS functionality, such as scalable, simple and fast QoS provisioning. Due to the fact that different networks have different characteristics, such as cost of bandwidth and performance, this basic QoS functionality may differ from one QoS domain to another. * BN <-> BN interface: provides the QoS functionality for a complete QoS domain by interacting with the interior <-> interior interfaces. * Host <-> BN interface: in addition to the basic QoS functionality, this interface has to provide a user with secure access to the network. Therefore, this interface will have to provide security functions, such as authentication and authorization. QoS domain QoS domain |---------------| |---------------| | | | | |---| |---| |---| |---| |---| |---| |---| |---| | |<->| |<->| |<->| |<->| |<->| |<->| |<->| | |---| |---| |---| |---| |---| |---| |---| |---| host | | | | host |---------------| |---------------| BN interior BN BN interior BN (access w/in (edge) (edge) w/in (access router) domain domain router) Figure 1: The end-to-end QoS architecture Different types of QoS requirements are imposed on these interfaces due to the different characteristics of the interfaces used in the QoS architecture. In addition, the different parts of the network often have different service and billing structures, with different trust models, all of which translate into signaling needs with varying degrees of complexity. These are the reasons for separating Westberg, et al. Expires November 2002 [Page 5] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 the end to end QoS management in several edge to edge QoS management domains. This draft describes a framework for edge-to-edge NSIS signaling that can mainly be applied in edge to edge networks, e.g., a QoS domain in Figure 1. The basic design goal of this framework is to satisfy the QoS requirements imposed by characteristics of different interfaces in an edge-to-edge network, that is: * interior <-> interior interface * BN <-> BN interface Furthermore, due to the fact that the vast majority of the traffic in typical networks is point-to-point unicast transport the QoS signaling mechanism must deal with unicast effectively. Therefore, this framework focuses on point-to-point and unicast scenarios. The edge-to-edge NSIS framework is also an open framework as it provides the basis for interoperability with other resource reservation schemes, AAA mechanisms,etc and can be extended to other signaling scenarios as well, such as end host - to - end host signaling. This draft is organized as follows. Section 3 describes the basic concepts and design structure of the framework for edge-to-edge NSIS signaling. Section 4 describes the NSIS edge-to-edge signaling protocol. Examples of NSIS edge-to-edge signaling protocol messages and of the functional operation of the edge-to-edge NSIS signaling framework are given in Appendix A, Appendix B, respectively. Note that these examples are only used for illustrative purposes. 3. Framework for Edge-to-Edge NSIS signaling In the QoS architecture as described in Section 2 there are three types of interfaces defined: * interior-to-interior * BN-to-BN Westberg, et al. Expires November 2002 [Page 6] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 * Host-to-BN The framework for edge-to-edge NSIS signaling is related only to the interfaces relevant to a single QoS domain, that is: * interior <-> interior interface * BN <-> BN interface The interior <-> interior interface provides basic QoS functionality, such as scalable, simple and fast QoS provisioning. Due to the fact that different networks have different characteristics, such as cost of bandwidth and performance, this basic QoS functionality may differ from one QoS domain to another. The BN <-> BN interface provides the QoS functionality for a complete QoS domain by interacting with the interior <-> interior interfaces. The basic idea of the framework is to satisfy the QoS requirements imposed by the characteristics of interior-to-interior interface and BN-to-BN interface. 3.1. Framework for Edge-to-Edge NSIS Signaling - Design Objectives The design of the edge-to-edge NSIS signaling framework is based on two main design goals. The first design goal is that the framework should enable scalable, simple and fast QoS provisioning on interior <-> interior interface (e.g. interior routers (see Figure 2)). Thus in the nodes on interior <-> interior interface there will be no per flow states, i.e. the reservation state will be per QoS traffic class, that will enable simple and scalable reservation state maintenance and consequently fast reservations. The second goal is that the edge-to-edge NSIS signaling framework should provide QoS guarantees for each flow (microflow or aggregate) incoming into the edge-to-edge domain. This implies that reservation requests of each flow on some nodes (e.g. access routers (see Figure 2)) needs to be related to the QoS traffic class reservation state in the interior nodes. These two goals are met by separating a complex reservation mechanism used in some nodes on BN <-> BN interface from a much simpler Westberg, et al. Expires November 2002 [Page 7] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 reservation mechanism needed in other nodes on interior <-> interior interface. In particular, nodes on BN <-> BN interface will maintain per-flow states i.e., are stateful. In the edge-to-edge NSIS signaling framework these nodes are denoted as edge nodes (see Figure 2). However, any nodes that maintain reservation states can satisfy this requirement. Note that the edge nodes that process the traffic that is incoming the edge-to-edge domain are denoted as ingress nodes and the edge nodes that process the traffic that is going out of the edge-to-edge domain are denoted as egress nodes. The nodes between these stateful nodes, that is the nodes on interior <-> interior interface can have a simpler execution by using only one aggregated reservation state per traffic class. In the NSIS edge-to- edge framework these nodes are denoted as interior nodes. The edges will generate reservation requests for each flow (micro- flow or aggregate), but in order to achieve simplicity in interior nodes, a measurement-based like approach on the number of the requested resources per QoS traffic class can be applied. In practice, this means that the aggregated reservation state per traffic class in the interior nodes is updated by a measurement-based algorithm that uses the requested and available resources as input. Unlike typical measurement based admission control (MBAC) algorithms, that apply admission control using data traffic measurements and available resources as input, the edge-to-edge NSIS framework applies admission control on resource parameter values included in the reservation requests, i.e. signaling messages and available resources per traffic c`lass. edge-to-edge network |---------------------------| | | |-----| |----| |----| |-----| | |<->| |<->| |<->| | |-----| |----| |----| |-----| | | |---------------------------| edge interior interior edge Figure 2: The edge-to-edge NSIS architecture Besides the two main design objectives the framework for edge-to-edge NSIS signaling is also intended as an open and extendible framework Westberg, et al. Expires November 2002 [Page 8] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 as it should provide the basis for interoperability with other mechanisms for example AAA mechanisms,etc and it can be extended to other signaling scenarios as well, such as end host - to - end host signaling. 3.2. Framework for Edge-to-Edge NSIS Signaling - Design Structure The framework for edge-to-edge NSIS signaling is structured in a component-based manner (see Figure 3), such that the design objectives given above are met. As each interface has a certain set of functions different from the other interface, in order to distinguish between them, in the framework design these sets of functionalities are structured into three types of components (see also Figure 3): _ _ _ _ _ _ _ _ _ _ _ _ / \ / \ Host Edge Interior Interior Edge Host |----| |---| |----| |----| |----| |----| |---| |----| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |----| |---| |----| |----| |----| |----| |---| |----| |HB-Q|<--|---|---|HB-Q|---|----|---|----|---|HB-Q|---|---|-->|HB-Q| |----| |---| |----| |----| |----| |----| |---| |----| | |<--|---|-->|BB-Q|<--|----|---|----|-->|BB-Q|<--|---|-->| | |----| |---| |----| |----| |----| |----| |---| |----| | |<->| |<->|II-Q|<->|II-Q|<->|II-Q|<->|II-Q|<->|---|<->| | |----| |---| |----| |----| |----| |----| |---| |----| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |----| |---| |----| |----| |----| |----| |---| |----| | \ / | | \ Edge-to-Edge Network / | | \ _ _ _ _ _ _ _ _ _ _ / | | end-to-end Protocol | |<--------------------------------------------------------->| Figure 3. Hierarchical structure of the edge-to-edge framework for QoS signaling * NSIS interior-interior (II-Q) component: must be part of all the nodes' functionality within a single domain. Westberg, et al. Expires November 2002 [Page 9] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 This component provides the basic QoS functionality for the interior nodes. The basic functionality in the interior nodes is related to the first design goal for the framework (see Section 3), that is to no per-flow state in interior node. This component handles the admission control on resource parameter values included in the reservation requests, i.e. signaling messages and available resources per QoS traffic class. * NSIS BN<->BN (BB-Q) component: must be part of border node functionality only. This component provides the QoS functionality for a whole single QoS domain by interacting with the interior <-> interior interfaces. Thus the second design goal for the edge-to-edge QoS signaling framework (see Section 3), i.e. that the framework even though stateless should associate each reservation to each flow (microflow or aggregate) in order to provide certain QoS guarantees for each flow is achieved by these components. Interior nodes in the edge-to-edge QoS signaling framework will not have any of this component's functionality. * NSIS Host<->BN (HB-Q) components: must be part border node functionality only. This component provides an interoperation between the edge-to-edge QoS signaling framework and other external mechanisms used for QoS management. In addition to the basic QoS functionality, this interface has to provide a user with secure access to the network. Therefore, this component will have to provide interoperation with security functions, such as authentication and authorization. Interior nodes in the edge-to-edge QoS signaling framework will not have any of this component's functionality. Each of these components have their own features. These features are described in the Sections 3.2.1, 3.2.2 and 3.2.3. respectively. Westberg, et al. Expires November 2002 [Page 10] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 3.2.1. NSIS interior-interior (II-Q) Component Features NSIS interior-interior (II-Q) component performs the following set of functions: * Admission control and/or resource reservation within a node. * Management of one reservation state per traffic class (e.g. PHB) by using a combination of the reservation soft state and explicit release principles. * Measurement of the user traffic load. * Stores a pre-configured threshold value on maximal allowable traffic load (or resources) per traffic class (e.g. PHB). * Adaptation to load sharing. Load sharing allows interior nodes to take advantage of multiple routes to the same destination by sending data via some or all of these available routes. The signaling protocol has to adapt to load sharing once it is used. * Severe congestion notification. This situation occurs as a result of route changes or a link failure. The NSIS interior-interior (II-Q) component has to notify the edges about the occurrence of this network event. 3.2.2. NSIS BN<->BN (BB-Q) Component Features NSIS BN<->BN (BB-Q) component performs the following set of functions: * Admission control and/or resource reservation within a domain. * Maintenance of flow identifier and reservation state per flow (or aggregated flows), e.g. by using soft state refresh. * Notification of the ingress border node IP address to the egress border node. * Notification of lost protocol signaling messages occurred in the communication path from the ingress border to the Westberg, et al. Expires November 2002 [Page 11] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 egress border nodes. * Notification of resource availability in all the nodes located in the communication path from the ingress to the egress nodes. * Severe congestion handling. Due to a route change or a link failure a severe congestion situation may occur. The egress border node is notified by NSIS II-Q component when such a severe congestion situation occurs. By using the BB-Q component egress border node notifies the ingress border node about this severe congestion situation. The ingress node is solving this situation by using a predefined policy, e.g., refuses new incoming flows and terminates a portion of the affected flows. * Transparent transport of NSIS interior-interior (II-Q), NSIS Host<->BN signaling components. 3.2.3. NSIS Host<->BN (HB-Q) Components Features NSIS Host<->BN (HB-Q) component functions are dependent on the protocols used externally to edge-to-edge network. These functions are related to interoperability with these protocols. One such function is: * Mapping of external QoS requests to resource requests used in the edge-to-edge QoS signaling framework. 4. Edge-to Edge QoS NSIS Protocol In the edge-to-edge NSIS signaling framework (see Figure 3) there are two types of protocols used: * end-to-end QoS protocol used externally to the edge-to-edge network * edge-to-edge QoS NSIS protocol used in the edge-to-edge network The End-to-end QoS (EEE-QoS) protocol could be any existing reservation protocol or a new one applied end-to-end (end host to end host). This protocol is used to signal the QoS requirements of the Westberg, et al. Expires November 2002 [Page 12] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 end hosts to the border nodes. RSVP is an example of such protocol. This protocol can also be the protocol developed by NSIS WG. The Edge-to-Edge QoS NSIS protocol is a new specialized protocol that is needed for signaling a limited set of QoS requirements related to interior-to-interior and BN-to-BN interface. In order to signal the QoS requirements for different components functionality sets, the edge-to-edge QoS NSIS protocol consists of the: * NSIS interior-interior (II-Q) signaling component This signaling component contains the information needed for the functionality of the NSIS interior-interior (II-Q) component for all the nodes in the edge-to-edge network (see Section 4, Figure 3). * NSIS BN<->BN (BB-Q) signaling component This signaling component contains the information needed for the functionality of the NSIS BN<->BN (BB-Q) component for all the border nodes in the edge-to-edge network (see Section 4, Figure 3). This component is not processed in interior nodes. * NSIS Host<->BN (HB-Q) signaling component This component contains the information needed for the functionality of the NSIS Host<->BN (BB-Q) component for all the border nodes in the edge-to-edge network (see Section 4, Figure 3). This component is not processed in interior nodes. Note that, signaling component related to the NSIS Host<->BN (BB-Q) component may also be assumed as implicitly part of the edge-to-edge QoS NSIS protocol functionality. The explicit definition of this NSIS BN<->BN (BB-Q) signaling component is dependent of the external QoS mechanisms and security protocols and is left out of this draft. Definition of edge-to-edge NSIS signaling protocol are outside of the scope of this draft. However, for illustrative purposes examples of these messages are given in Appendix A. Westberg, et al. Expires November 2002 [Page 13] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 5. Edge-to-Edge NSIS signaling framework operation The edge-to-edge NSIS signaling framework operation is belongs to the solutions/implementation space and therefore is outside the scope of this draft. However, for the sake of clarity of concepts and illustrative purposes some possible examples of edge-to-edge NSIS signaling framework operation are given in Appendix B. 6. Conclusion This draft presents the edge-to-edge NSIS signaling framework, that can be used as input to the NSIS signaling framework. It is a simple, scalable framework that enables fast QoS reservations and provides per flow (microflow or aggregate) QoS guarantees. Furthermore it is also an interoperable and extendible framework as it can be extended for signaling scenarios other than edge-to-edge, such as signaling end-host to end-host. 7. Appendix A: Examples of Edge-to-Edge NSIS Signaling Messages This Appendix presents examples of messages that can be used for signaling of the edge-to-edge QoS NSIS protocol signaling components in the nodes in the communication path in the edge-to-edge network. Their description in this draft is to be used for illustrating the functionality of the edge-to-edge QoS signaling framework. 7.1. NSIS BN<->BN (BB-Q) Signaling Messages Signaling messages that can be used in the communication between the NSIS BN<->BN (BB-Q) signaling components are: * Border to Border Reservation Request (BBQ-RQ) Initiates or updates the BBQ state in the egress. It is generated by the ingress node. * Border to Border Reservation Refresh (BBQ-RF) Refreshes the BBQ states located in the egress. It is generated by the ingress node. Westberg, et al. Expires November 2002 [Page 14] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 * Border to Border Release Request (BBQ-LQ) Explicitly release the BBQ state. It is generated by the ingress node. * Border to Border Reservation Report (BBQ-RR) Reports that a BBQ-RQ/IIQ-RQ message has been received and that the request has been admitted or rejected. It is sent by the egress to the ingress node. * Border to Border Refresh Report (BBQ-FR) Reports that a BBQ-RF/IIQ-RF message has been received and has been processed. It is sent by the egress to the ingress node. * Border to Border Congestion Report (BBQ-CR) Used for severe congestion notification and is sent by egress to ingress. In all the messages generated by the ingress node in order to associate the information between the ingress node and egress node in an edge-to-edge network, an object will be included. i.e. Border to Border Request Info (BBQ-RI) object. This object is part of any BBQ message that is sent from the ingress to egress node. It contains the information that is required by the egress node to associate a IIQ signaling message to for example the BBQ flow ID and/or the IP address of the ingress node. It is inserted by the ingress node. Furthermore in case of bidirectional reservations this object might have to carry also the amount of resources needed in the reverse path. 7.2. NSIS Interior <-> Interior (II-Q) Signaling Messages Signaling messages that can be used in the communication between the Interior <-> Interior (II-Q) signaling components are: * Interior to Interior Reservation Request (IIQ-RQ) Initiates the IIQ reservation state on all nodes located on the communication path between the ingress and egress Westberg, et al. Expires November 2002 [Page 15] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 nodes according to the external reservation request. This message can be encapsulated in the BBQ-RQ (BBQ Reservation Request) message. * Interior to Interior Reservation Refresh (IIQ-RF) Refreshes the IIQ reservation soft state on all nodes located on the communication path between the ingress and egress nodes according to the resource reservation request that was successfully processed by the IIQ functionality during a previous refresh period. If this reservation state does not receive a IIQ-RF message within a refresh period, reserved resources associated to this IIQ-RF message will be released automatically. This message can be encapsulated in the BBQ-RF (BBQ Reservation Refresh) message. * Interior to Interior Release Request (IIQ-LQ) Explicitly releases the reserved resources for a particular flow from a IIQ reservation state. Any node that receives this message will release the requested resources associated with it, by subtracting the amount of IIQ-LQ requested resources from the total reserved amount of resources stored in the IIQ reservation state. This message can be encapsulated in the BBQ-LQ (BBQ Release Request) message. 8. Appendix B: Examples of Edge-to-Edge NSIS signaling framework operation In this Appendix, three illustrative examples of the functional operation of the edge-to-edge NSIS framework will be described: * Sender-initiated Unidirectional Normal Operation Describes the scenario for successful and unsuccessful unicast reservations between edges of a domain. * Sender-initiated Fault Handling Describes the severe congestion handling for unidirectional reservations between edges of a domain Westberg, et al. Expires November 2002 [Page 16] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 * Sender initiated Bi-directional Normal Operation Describes the scenario for successful bi-directional reservation between edges of a domain. 8.1. Normal Operation for Unidirectional Reservation This section describes an example of sender-initiated unidirectional normal operation. This operation is described by means of flow diagrams of signaling messages used during the sender-initiated unidirectional normal. In particular, Figure B-1 and Figure B-2 depict the successful reservation and Figure B-3 depicts the unsuccessful reservation. In the successful reservation procedure the IIQ-RQ (IIQ- Reservation Request) and IIQ-RF (IIQ- Reservation Refresh) are encapsulated into the BBQ-RQ (BBQ- Reservation Request) and BBQ-RF (BBQ- Reservation Refresh) messages, respectively. The interior nodes process only the IIQ-RQ and IIQ-RF messages, respectively. This means that the IIQ information carried by the IIQ messages is processed and used by the interior nodes, without processing or using any of the BBQ information. If a reservation request can be supported by a node then the request is sent further towards the egress node. If the request can not be supported by a node, than the IIQ-RQ is marked (special information in the IIQ-RQ message that can be marked). The BBQ information contained in the BBQ-RQ and BBQ-RF messages is only processed at the edge nodes. Note that each BBQ message generated by the ingress node carries the Border to Border Request Info (BBQ-RI) object that contains the information required by the egress node to associate a IIQ signaling message encapsulated in the BBQ message to for example the BBQ flow ID and/or the IP address of the ingress node. The egress nodes receiving the BBQ-RQ or BBQ-RF messages creates a BBQ Reservation Report (BBQ-RR) or a BBQ Refresh Report (BBQ-FR). If the IIQ messages that were received by the egress node were marked than the BBQ report messages will be marked as well. In this way the egress node will notify the ingress node about the resource availability in the communication path between the ingress and egress node. Westberg, et al. Expires November 2002 [Page 17] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 Ingress Interior Interior Egress external | | | | reservation | | | request | | | | -------->| BBQ-RQ | | | |(IIQ- | | | | Reservation| | | | Request) | | | | | BBQ-RQ | | |----------->|(IIQ-Reservation| | | | Request) | | | | | BBQ-RQ | | |--------------->|(IIQ-Reservation| | | | Request) | | | | |external | | |--------------->|reservation | | | |request | | | |---> | BBQ-Reservation Report | |<-----------|----------------|----------------| | | Traffic(user) | | | | Data | | -------->|----------->|--------------->|--------------->|---> external | | | | reservation | | | refresh | | | | -------->| BBQ-RF | | | |(IIQ- | | | | Reservation| | | | Refresh) | | | | | BBQ-RF | | |----------->|(IIQ-Reservation| | | | Refresh) | | | | | BBQ-RF | | |--------------->|(IIQ-Reservation| | | | Refresh) | | | | |external | | |--------------->|reservation | | | |refresh | | | |---> | BBQ-Refresh Report| | |<-----------|----------------|----------------| | | | | Figure B-1: Unidirectional Normal operation for successful reservation Westberg, et al. Expires November 2002 [Page 18] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 The explicit release procedure is depicted in Figure B-2. The IIQ Release Request (IIQ-LQ) message is encapsulated within a BBQ-Release Request (BBQ-LQ) message. Same as previously, interior nodes process only the IIQ-LQ. The BBQ information contained in the BBQ-LQ is only processed at the edge nodes. Ingress Interior Interior Egress external | | | | release | | | | request | | | | -------->| BBQ-LQ | | | |(IIQ-Release| | | | Request) | | | | | BBQ-LQ | | |----------->|(IIQ-Release | | | | Request) | | | | | BBQ-LQ | | |------------>|(IIQ-Release | | | | Request) | | | | |external | | |------------>|release | | | |request | | | |---> Figure B-2: Unidirectional Normal operation for explicit release The unsuccessful reservation procedure is depicted in Figure B-3. As already mentioned, if the request can not be supported by a node, than the IIQ-RQ is marked (special information in the IIQ-RQ message that can be marked) by this node. Besides marking this will also include its identity into the IIQ-RQ message. All the subsequent nodes in the communication path towards the egress node will just forward the marked IIQ-RQ message without processing it. The egress node that receives the marked IIQ-RQ it will create a BBQ Reservation Report message. This message will be marked as unsuccessful and it will include the identity of the node that could not support the reservation request. When the ingress receives the marked BBQ Reservation Report message it will have to generate a BBQ Release Request/IIQ Release Request message in order to release unnecessary reserved resources in some Westberg, et al. Expires November 2002 [Page 19] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 nodes. The IIQ-LQ message will release the same amount of resources as the amount of resources requested by the IIQ Reservation Request that could not be supported by a node. All the nodes that process the IIQ-LQ message will release these requested resources. When the IIQ-LQ message reaches the node that could not support the reservation request, the IIQ-LQ message is discarded. Ingress Interior Interior Egress external | | | | reservation | | | request | | | | -------->| BBQ-RQ | | | | (IIQ- | | | | Reservation| | | | Request) | | | | |BBQ-RQ | | |----------->|(IIQ- | | | |Reservation | | | | Request) | | | | | BBQ-RQ | | |----------->|(IIQ- | | | |Reservation | | | |Request | | | |(Marked)) | | | M |external | | M------------>|reserv- | | | |ation | | | |request | | | |---> | BBQ-Reservation Report (Marked) | |<-----------|------------|-------------| | BBQ-LQ | | | |(IIQ-Release| | | | Request) | | | | | BBQ-LQ | | |----------->|(IIQ-Release| | | | Request) | | | | | | | |----------->| | | | | | | | | | Figure B-3: Unidirectional Normal operation for unsuccessful reservation Westberg, et al. Expires November 2002 [Page 20] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 8.2. Fault handling for unidirectional reservation This section describes an example of sender-initiated unidirectional fault handling operation. The fault handling operation explained in this section is the severe congestion handling procedure. This operation is described by means of flow diagrams given in Figure B-4. Severe congestion in a network is a result of a link or router failure. Routing algorithms in networks will adapt to severe congestion by changing the routing decisions to reflect changes in the topology and traffic volume. As a result the re-routed traffic will follow a new path, which may result in overloaded nodes as they need to support more traffic than their capacity allows. This is a severe congestion occurrence in the communication path. In the edge-to-edge QoS signaling framework this event needs to be signaled to the ingress nodes. This will be done by the interior nodes, that will first detect this occurrence and then by means of signaling messages or data traffic will notify the ingress nodes. The ingress node has to resolve this situation based on its predefined policies related to the flows and QoS guarantees. One can think of various detection and notification methods for the interior nodes, such as marking of all the data packets passing through a severe congested node or marking the IIQ signaling messages only. In this draft only one method is considered. This is the proportional marking method, where the number of the remarked data packets is proportional to the detected overload. The severely congested interior node will remark the user data packets with with a specific severe congestion ID, proportionally to the detected overload. Once the severe congestion marked packets arrive at the egress node, the egress node will generate a BBQ_Congestion_Report message that will be sent to the ingress node. This message will contain the over- allocation volume of the flow in question, e.g., a blocking probability. For each flow ID, the egress node will count the number of severe congested marked bytes and the number of unmarked bytes, and it will calculate the blocking probability (Pdrop) using the formula (1): Pdrop = Bm/(Bm + Bu) (1) where Bm = number of severe congested marked bytes and Bu = number Westberg, et al. Expires November 2002 [Page 21] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 of unmarked bytes. The ingress node, based on this blocking probability, might terminate the flow. That is, for a higher blocking probability there is a higher chance that the flow will be terminated. If a flow needs to be terminated, the ingress node will generate a IIQ_Release Request message for this flow. Ingress Interior Interior Egress | | | | sent) | | | | user |(sent) | | | | user data | | | data | | | | -------->|---------->| (sent) user data | user data | | |------------------->S(# marked bytes) | | | S------------------->| | | S(# unmarked bytes) | | | S------------------->| | | | | | | | | | | | | | (BBQ_Congestion_Report ("S" marked + Pdrop)) | external |<----------|--------------------|--------------------| Error | | | | <--------| | | | Terminate| | | | flow? |BBQ-LQ | | | YES |(IIQ_ | | | | Release | | | | Request) | BBQ-LQ | | | |(IIQ_Release Request) BBQ-LQ | |---------->| |(IIQ Release Request) | |------------------->| | | | |------------------->| | | | | | | | | Figure B-4: Unidirectional edge-to-edge NSIS operation in case of severe congestion handling using proportional marking Westberg, et al. Expires November 2002 [Page 22] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 8.3. Normal Operation for bidirectional (successful) reservation This section describes an example of sender-initiated bi-directional normal operation for successful reservation. This operation is described by means of flow diagrams given in Figure B-5, Figure B-6, Figure B-7. The method for bi-directional reservations is based on combining two uni-directional reservations. This means that the signaling messages from the sender of the the bi-directional reservation towards a receiver are likely to follow a different path than messages traveling in the opposite direction. The edge nodes that support a bi-directional reservations have to satisfy the following requirements: * Be able to distinguish between a uni-directional and a bi-directional resource reservation BBQ signaling message. * When an egress node receives a bi-directional BBQ/IIQ reservation message it will have to construct a uni-directional BBQ signaling message and an uni-directional IIQ signaling message that will be sent in the reverse direction. The destination IP address (and the source IP address) of this uni-directional IIQ should be such that it should reach the sender of the bi-directional reservation. * It should be possible that the ingress and egress create a BBQ state that maintains a bi-directional flow specification. As already mentioned the forwarding path, i.e., ingress to egress, may be different from the reverse path, i.e., egress to ingress. This means that the forwarding path and the reverse path may go though different interior nodes and ingress nodes than the reverse path. Note that in order to simplify the description of this feature, in this Section it is considered that the that the ingress/egress pairs of nodes in the forwarding and reverse path are the same. In practice these might be different. The flow diagram examples shown in Figure 5-5, Figure 5-6 and Figure 5-7 are emphasizing the normal operation for an initial bi- directional reservation, for a refresh procedure and for an explicit release procedure, respectively. Westberg, et al. Expires November 2002 [Page 23] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 The ingress node that triggers a bi-directional reservation, (see Figure 5-5), will send a BBQ-RQ message/IIQ-RQ towards the egress node. This message will carry the BBQ Request Info object to notify the egress node that the BBQ-RQ/IIQ-RQ message is a bi-directional message. Note that this message may also include the amount of resources that are requested for the reverse path. These two messages are denoted as IIQ-RQ(forward) and BBQ_ReqInfo(Bi- forward). The egress by processing the BBQ_ReqInfo object from the BBQ_ReqInfo(Bi-forward) will recognize the bidirectional resource request. The egress node will have to reuse the BBQ-RQ, IIQ-RQ (and the BBQ_ReqInfo object) message for the reverse direction. These messages are denoted as BBQ-RQ(reverse)/IIQ_RQ(reverse). The BBQ-RQ(reverse)/IIQ-RQ(reverse) (and BBQ_ReqInfo(reverse)object) messages are almost the same as the BBQ-RQ(forward)/IIQ-RQ(forward) messages (almost all fields included in the Bi-forward messages are copied into the reverse messages). The difference is related to the IP source and IP destination addresses of these messages that have to be chosen such that the messages are sent to/from the same ingress/egress pair of nodes. Moreover, the amount of requested resources is equal to the amount of resources that has been carried by the BBQ_ReqInfo(bi-forward) object. Ingress Interior Interior Egress | BBQ-RQ (forward)| | | external|(IIQ-RQ(forward) | | | request| | BBQ-RQ(forward) | | ------->|---------------->|(IIQ-RQ(forward))| | | | |BBQ-RQ(forward) | | |---------------->|(IIQ-RQ(forward))| | | |---------------->| | | (BBQ-RQ(reverse) | | | ((IIQ-RQ(reverse) | | |<----------------|-----------------| | BBQ-RQ(reverse)| | | |(IIQ-RQ(reverse))| | | |<----------------| | | | | | | | BBQ Reservation Report(reverse) | | |---------------------------------------------------->| | |BBQ Reservation Report(Bi-forward) | |<----------------------------------------------------| Figure B-5: Bi-directional resource reservation flow diagram for successful reservation (initial reservation) Westberg, et al. Expires November 2002 [Page 24] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 A similar approach is used for the refresh procedure, see Figure B-6, and the explicit release procedure, see Figure B-7. Ingress Interior Interior Egress | BBQ-RF (forward)| | | external|(IIQ-RF(forward) | | | refresh| | BBQ-RF(forward)| | ------->|---------------->|(IIQ-RF(forward) | BBQ-RF(forward)| | |----------------->| (IIQ-RF(forward))| | | |----------------->| | | (BBQ-RF(reverse) | | | ((IIQ-RF(reverse) | | |<-----------------|------------------| | BBQ-RF(reverse)| | | |(IIQ-RF(reverse))| | | |<----------------| | | | | | | | BBQ Refresh Report(reverse) | | |---------------- ------------------------------------->| | |BBQ Refresh Report(Bi-forward) | |<------------------------------------------------------| | | | | Figure B-6: Bi-directional resource reservation flow diagram for successful reservation (refresh procedure) Ingress Interior Interior Egress | BBQ-LQ (forward)| | | external |(IIQ-LQ(forward) | | | release | | BBQ-LQ(forward) | | -------> |---------------->|(IIQ-LQ(forward)) | BBQ-LQ(forward) | | |----------------->| (IIQ-LQ(forward))| | | |------------------>| | | (BBQ-LQ(reverse) | | | ((IIQ-LQ(reverse) | | |<-----------------|-------------------| |BBQ-LQ(reverse) | | | |(IIQ-LQ(reverse))| | | |<----------------| | | | | | | Figure B-7: Bi-directional resource reservation flow diagram for successful reservation (explicit release procedure) Westberg, et al. Expires November 2002 [Page 25] Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002 9. Authors' Address Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden EMail: Lars.Westberg@era.ericsson.se Georgios Karagiannis Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands EMail: Georgios.Karagiannis@eln.ericsson.se David Partain Ericsson Radio Systems AB P.O. Box 1248 SE-581 12 Linkoping Sweden EMail: David.Partain@ericsson.com Vlora Rexhepi Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands EMail: Vlora.Rexhepi@eln.ericsson.se Westberg, et al. Expires November 2002 [Page 26]