Network Working Group Jyh-Cheng Chen INTERNET-DRAFT National Tsing Hua University Internet Engineering Task Force Anthony McAuley draft-itsumo-dsnp-03.txt Telcordia Technologies, Inc. Date: February 15, 2006 Venkatesh Sarangan Expires: August 19, 2006 Oklahoma State University Shinichi Baba Toshiba Corporation Yoshihiro Ohba Toshiba America Research Inc. Dynamic Service Negotiation Protocol (DSNP) Status of this memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on August 19, 2006. Copyright Notice J.-C. Chen, et al. Expires August 2006 [Page 1]
Internet Draft DSNP February 2006 Copyright (C) The Internet Society (2006). Abstract This memo presents the specification of Dynamic Service Negotiation Protocol (DSNP). DSNP is a protocol to negotiate the SLS (Service Level Specification) in IP layer. It can be used for service negotiation from host to network, network to host, and network to network. The automated negotiation makes service negotiation efficient in terms of time, cost, and correctness, etc. The dynamic negotiation not only allows users to adapt their needs dynamically, but also let providers better utilize the network. The DSNP messages and packet formats are detailed. DSNP can be used in both wireline and wireless networks. It is, however, particularly useful in mobile environment. To demonstrate the usefulness of DSNP, a reference wireless QoS architecture is presented. Exemplary applications are illustrated. Table of Contents 1. Introduction 2. Protocol Overview 3. DSNP Messages 4. Basic Operation 4.1 Reference Architecture 4.2 Reference QoS Architecture 4.3 Distribution of QoS Profile and Traffic Conditioning 5. Example Applications 5.1 Initial QoS Negotiation 5.2 Client Moves within the Same Domain 5.3 Client Renegotiates SLS within the Same Domain 5.4 Client Moves into a New Domain 6. DSNP Message Format 7. Acknowledgments 8. References 9. Authors' Addresses 1. Introduction Today, many different wireless systems exist, ranging from PANs (Personal Area Networks), wireless LANs (Local Area Networks) to outdoor cellular systems. They are typically not compatible with each other, making it difficult to roam from one system to another. PANs, Wireless LANs, and cellular wireless systems are also being developed and are evolving independently (e.g., from 3G to 4G, 802.11 to 802.11a/802.11b, HIPERLAN to HIPERLAN II, etc.). Although ITU IMT-2000 [IMT97] has been trying to unify J.-C. Chen, et al. Expires August 2006 [Page 2]
Internet Draft DSNP February 2006 third-generation (3G) wireless systems, incompatible systems are expected to co-exist in the future. No wireless technology has emerged as a common and long-term universal solution. IP (Internet Protocol), which is already a universal network-layer protocol for wireline packet networks, is becoming a promising universal network-layer protocol over all wireless systems. An IP device, with multiple radio interfaces or software radio, could roam between different wireless systems if they all support IP as a common network layer. Unlike today's radio systems that continue to depend heavily on proprietary technologies, IP provides a globally successful open infrastructure for services and applications. Such an all-IP wireless and wireline network could also make wireless networks more robust, scalable, and cost effective. A key challenge in realizing the all-IP wireless networks is how to guarantee Quality of Service (QoS). To guarantee QoS on the Internet, Int-Serv (Integrated Services) [INT94] and Diff-Serv (Differentiated Services) [DIFF98], which differ in the technique for resource provisioning and the granularity of service differentiation, have been proposed. Both approaches, however, are limited to stationary hosts and cannot be applied to the mobile environment directly. Today the service level agreement (SLA) is usually agreed, either verbally or in writing, by both the user and the service provider when a user signs up for a service. The service provider stores it in some repository and uses it to condition the traffic sending to/from the user. To change the SLA, normally a user has to contact and negotiate with the authority of the service provider, which then manually changes it. Usually service provider allows this kind of re-negotiation or changes only in a large time scale, for instance, once per year. It is expected that a user will use a different terminal with different capability in different situation. For example, PC may be used at home or inside an office. While driving, small handset might be more suitable. PDA or laptop will be used when traveling. They are different not only in size, but also in processing and communication capabilities. Different applications will also be used in different terminals. They generally require different bandwidth for network transmission. As stated above, mobility and the diversity in transmission media (Bluetooth, 802.11, cellular, etc.) and user terminals (PC, laptop, PDA, etc.) create a very dynamic environment. It is hardly for a service provider to plan uniform resource in all networks and J.-C. Chen, et al. Expires August 2006 [Page 3]
Internet Draft DSNP February 2006 to envision fixed bandwidth requirement from all users. Users are also hardly to project what they really need due to mobility and the difference in terminal they may carry. In addition, users may roam to other service providers and still wish to enjoy the same QoS as they had in the home provider. It is desirable that there is a way to negotiate the service dynamically. This dynamic service negotiation should be automated and should be able to do in a small time scale in opposite to today's manual negotiation in a large time scale. A user should be able to negotiate with the home and visiting service providers dynamically. Similarly, the service provider can also negotiate with a user depending on the resource available. A service provider may advertise unused resource if the resource is underutilized. On the other hand, a service provider can negotiate with users to lower their service grade if the network is over-provisioned. While the user is roaming, the home and visiting providers should also be able to negotiate with each other to decide the service which can be offered to the user. There should be a standard protocol which can be used for service negotiation for multi-vendors and multi-service providers. 2. Protocol Overview DSNP (Dynamic Service Negotiation Protocol) is a protocol to dynamically negotiate the SLS (Service Level Specification) [DIFF01] in IP layer. DSNP can be used for service negotiation from host to network, network to host, and network to network. The automated negotiation makes service negotiation efficient in terms of time, cost, and correctness, etc. DSNP can be used in both wireline and wireless networks. It is, however, particularly useful in mobile environment. For example, a mobile user may roam to a new service provider which does not have any contract with either the mobile user or its old service provider. The inter-domain negotiation might be necessary in order to get network service. Even though the old and new providers have certain level of service agreement, the new service provider may still need to negotiate with the old service provider. When roaming inside the same domain, the following are some motivation to support dynamic intra-domain negotiation: (1) A user may carry a different terminal at different time to access the network. The capabilities of these terminals may be different, thus the network resource requirements may be different too. (2) A user may roam to networks with different physical and link layers, for instance, from Bluetooth to IEEE 802.11 to IS-95 (or other outdoor cellular systems). The available resource J.-C. Chen, et al. Expires August 2006 [Page 4]
Internet Draft DSNP February 2006 typically are different in different type of networks. (3) Due to mobility, the provisioning of network resource may not be accurate for actual demand. For example, a special event in a city may gather many unexpected network users. Dynamic service negotiation not only allows users to adapt their needs dynamically, but also let the service provider better utilize the network. Service negotiation may involve human. If so, some applications may be needed. The user or the service provider may also pre-define and store their policy so the negotiation can be done without human interactions. In either case, DSNP is a protocol for hosts and networks to negotiate SLS in IP layer. DSNP can be used in any architecture frameworks. It is independent of network architecture, and how resource reservation or provisioning is done. DSNP, however, is particularly useful in Diff-Serv [DIFF98]. Diff-Serv is built on the concept of classifying packets and keeping per-customer state at the network edge and letting the core deal with aggregates of traffic. In operation, routers use DS (Diff-Serv) byte to differentiate traffic flows belonging to different service classes. The edge routers perform conditioning functions to keep traffic "in profile" with the TCA (Traffic Conditioning Agreement). In order to condition the traffic properly, the edge router needs to know the QoS profile of a user. The changes in SLS should be known by the necessary edge routers (ERs). In mobile environment, there should be an efficient way to distribute mobile's QoS profile to possible ERs. It is also desirable to reduce QoS-related signalling messages for every handoff so fast handoff can be achieved. Next section presents the DSNP messages. To demonstrate the usefulness of DSNP, Section 4 presents a reference architecture, then shows a way to distribute QoS profile once a negotiation is done so mobile users can perform fast handoff while also guarantee the same level of QoS. Section 5 shows some exemplary applications of DSNP. The DSNP message format is presented in Section 6. 3. DSNP Messages 3.1 Terminology 3.1.1 DSNP Client J.-C. Chen, et al. Expires August 2006 [Page 5]
Internet Draft DSNP February 2006 A DSNP client is the one that initiates the SLS negotiation. 3.1.2 DSNP Server A DSNP server is the one that responds to the SLS negotiation. For example, when a host wants to negotiate with the service provider for a SLS, the host acts as the DSNP client. The service provider acts as the DSNP server. When a service provider starts the SLS negotiation with a host, the service provider acts as the DSNP client and the host acts as the DSNP server. When a service provider negotiates a SLS with another service provider, the former acts as the DSNP client and the latter acts as the DSNP server. 3.2 DSNP Message Types This section explains the various messages used in DSNP. An intra-domain negotiation scenario is assumed. A host acts as the DSNP client and a service provider's QoS authority acts as the DSNP server. o SLS_LIST_REQUEST: This message is sent by a DSNP client to the DSNP server, to request for a list of SLSs offered by the DSNP server. A DSNP client may send this message when it has just booted up and does not have any idea about the services provided by the network. o SLS_LIST_RESPONSE: This message is sent by the DSNP server in response to the SLS_LIST_REQUEST message. This message lists all the SLSs that are provided by the DSNP server. The cost and the time of availability for each service may also be included in the list. o SLS_NEGO_REQUEST: This message is usually sent by an DSNP client to the DSNP server, to request for a particular SLS. The requested SLS could either be customized or one of those listed in the SLS_LIST_RESPONSE message. The time for which the SLS is requested may also be included in the message. This message is used for both requesting a new SLS as well as updating an existing one. The DSNP server can also send this message to the hosts under some circumstances. For example, if network resources become scarce, the DSNP serversends this message to the hosts that have a SLS with the DSNP server requesting them to update their existing SLS to suit the current network conditions. The DSNP server could offer cost incentives to the hosts that accept the suggested SLS. Similarly, when there are unused J.-C. Chen, et al. Expires August 2006 [Page 6]
Internet Draft DSNP February 2006 resources available, the DSNP server could offer them at a lower price to the DSNP clients. It could do an advertisement by sending out SLS_NEGO_REQUEST messages with the available SLSs and the cost. Also, if the DSNP server wants to forcefully terminate a SLS of an DSNP client due to some reason, it sends a SLS_NEGO_REQUEST message to the DSNP client with appropriate fields set to ZERO. o SLS_NEGO_RESPONSE: This message is sent in response to the SLS_NEGO_REQUEST. This message indicates whether the requested SLS was accepted or not. If the requested SLS was not accepted, then the reason for not accepting is also provided. For example, if the DSNP server does not accept the SLS of an DSNP client due to lack of resources, it sends back a SLS_NEGO_RESPONSE indicating a reject along with the maximum SLS that could be supported. o SLS_STAT_REQUEST: This message is sent by a DSNP client to the DSNP Server asking for a feedback on the statistics of the actual usage of each SLS. The DSNP client could ask for statistics like packet loss, throughput, average delay, jitter, and total number of octets sent from/forwarded to the DSNP client. o SLS_STAT_RESPONSE: This message is sent by the DSNP server in response to a SLS_STAT_REQUEST message. The DSNP server collects the necessary information and sends it to the requested DSNP client. The above message types are explained in an intra-domain negotiation scenario. The same messages could also be used in an inter-domain negotiation. In an inter-domain negotiation, one network requests for some service (and hence acts as the DSNP client) and the other provides the requested service (and hence acts the DSNP server). The nature of interaction hence remains the same as in an intra-domain negotiation. 4. Basic Operation 4.1 Reference Architecture To demonstrate the usefulness of DSNP, we use the ITSUMO architecture as a reference architecture. DSNP, however, can be used in any network architecture. ITSUMO [ITSUMO00] is a research project that focuses on the design of next generation IP networks. It envisions an end-to-end wireless/wireline IP platform for supporting real-time and J.-C. Chen, et al. Expires August 2006 [Page 7]
Internet Draft DSNP February 2006 non-real-time multimedia services in the future. Its goal is to use IP and next generation wireless technologies to design a wireless platform that allows mobile users to access all services on a next generation Internet. Figure 1 depicts the end-to-end packet platform of ITSUMO's all IP wireless/wireline network, which comprises all IP wireless access networks and a packet switched IP backbone network. The IP backbone network is an end-to-end wireline IP infrastructure that will comprise regional providers' wireline IP networks that are connected through the Internet. Besides mobile stations/terminals, a wireless access network also comprises a radio access network (RAN), and an edge router and controller (ERC) [ITSUMO99]. In order to support the needs of its users, a wireless access network interacts with the network control entities that are shown as Domain Control Agent (DCA) in Figure 1. What follows is a brief description of these elements and their functions. 4.1.1 Mobile Station (MS) It is the user mobile terminal that allows users to communicate, and also provides means of interactions and control between users and the network. 4.1.2 Radio Access Network (RAN) The radio access network (RAN) represents the wireless and back-haul infrastructure that provides MSs with wireless access to the wireline infrastructure. A RAN usually comprises a set of base stations and base station controllers. In IMT-2000 [IMT97], RANs use programmable software radios to provide flexibility across frequency bands at the MS and across the RAN. ITSUMO strives to remain independent from the underlying RAN technology and to minimize the restriction (or requirements) that it places on (or expects from) a RAN. 4.1.3 Edge Router & Controller (ERC) An ERC is a routing and control system that connects a wireless access network to a regional wireline IP network. Although Figure 1 depicts one RAN per ERC, in practice, each ERC may support several RANs. An ERC comprises two functional entities, an edge router (ER) and an edge control agent (ECA). The ER is an IP router, while the ECA is an intelligent agent that interacts with the domain control agent (DCA) to control the RANs as well as support necessary network-wide control tasks. In the IP parlance, each ERC is the default gateway of all IP MSs that are supported by RANs that are connected to it. J.-C. Chen, et al. Expires August 2006 [Page 8]
Internet Draft DSNP February 2006 4.1.4 Domain Control Agent (DCA) The domain control agent (DCA) provides connection management as well as means for interaction between users and network control system and interaction among network control entities. Furthermore, the DCA also supports: (1) Mobility management, (2) Authentication, Authorization, and Accounting (AAA), and (3) QoS management (MAAAQ) functions for mobile users. These functional entities usually reside on the wireline backbone, and are part of the overall control system of the end-to-end platform. As Figure 1 indicates the home and visiting DCA entities may either interact directly or via a third party Inter-Domain Control Agent (IDCA) on the global Internet. In the latter case, the IDCA entity serves as a trusted broker between the home and visiting network DCAs. <-- Visiting Network --> <---- Home Network ----> +---------------+ | Inter-Domain | | Control Agent | +---------------+ | | +---------------+ | +---------------+ | Domain | | | Domain | | Control Agent | | | Control Agent | +---------------+ | +---------------+ | | | ___|___ ___|___ ___|___ / \ / \ / \ / \ / \ / \ /Regional IP\___________/ Internet \___________/Regional IP\ \ Network / \ / \ Network / \ / \ / \ / ---\_______/--- \_______/ ---\_______/--- | | | | +-----+ +-----+ +-----+ +-----+ | ERC | | ERC | | ERC | | ERC | +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | | __|__ __|__ __|__ __|__ / \ / \ / \ / \ J.-C. Chen, et al. Expires August 2006 [Page 9]
Internet Draft DSNP February 2006 / Radio \ / Radio \ / Radio \ / Radio \ / Access \ / Access \ / Access \ / Access \ \ Network / \ Network / \ Network / \ Network / \ / \ / \ / \ / \_____/ \_____/ \_____/ \_____/ | | | | v v v v +----+ +----+ +----+ +----+ | MS | | MS | | MS | | MS | +----+ +----+ +----+ +----+ FIGURE 1: ITSUMO long term network architecture 4.2 Reference QoS Architecture This section presents a reference QoS architecture which is based on the ITSUMO overall architecture. Again, DSNP is independent of QoS architecture. <----------- DOMAIN 1 -----------> <---------- DOMAIN 2 -------------> +--------------+ +---------------+ | QoS Global | | QoS Global | | Server (QGS) | | Server (QGS) | +--------------+ +---------------+ | | ___|___ _______ ___|___ / \ / \ / \ / \ / \ / \ /Regional IP\__________/ Global IP \__________/Regional IP\ \ Network / \ Network / \ Network / \ /---------\ \ / ----------\ / --\_______/--- \ \_______/ | \_______/----- | | \ | | | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | QLN | | QLN | | QLN | | QLN | | QLN | | QLN | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ __|__ __|__ __|__ __|__ __|__ __|__ / \ / \ / \ / \ / \ / \ / Radio \ / Radio \ / Radio \ / Radio \ / Radio \ / Radio \ / Access \ / Access \ / Access \ / Access \ / Access \ / Access \ \ Network / \ Network / \ Network / \ Network / \ Network / \ Network / \ / \ / \ / \ / \ / \ / \_____/ \_____/ \_____/ \_____/ \_____/ \_____/ J.-C. Chen, et al. Expires August 2006 [Page 10]
Internet Draft DSNP February 2006 | | | | | | v v v v v v +----+ | MS | --> +----+ FIGURE 2: Reference QoS architecture As that in the ITSUMO overall architecture, there is at least one logical global server and several local nodes in each administrative domain. The server is referred to as the QoS Global Server (or QGS), and local nodes are referred to as QoS local nodes (or QLN). The architecture is depicted in Figure 2. In addition to other necessary components in the system such as DHCP[DHCP97]/DRCP[DRCP00] server, AAA, etc., there are three major QoS components: 4.2.1 MS (Mobile Station) MS is the device that allows users to communicate, and also provides means of interaction between users and the networks. Traffic is generated/received by MS and may be queued in the MS while waiting for transmission/reception. 4.2.2 QGS (QoS Global Server) As shown in Figure 2, there is one logical QGS in each administrative domain. The QGS has the global information of the resource available in the whole domain. Essentially, it is a bandwidth broker with extension for wireless networks. The MS interacts with the QGS when the MS requests certain degree of QoS in the domain. The QGS is the entity for QoS negotiation and signaling between MS and the network control system, i.e. it is in control plan, as that of MGC (Media Gateway Controller) in MEGACO [MEGACO00]. The QGS decides what services are available for each MS and sends the decision to related QLNs. Thus, the QGS is an intelligent entity for decision making. It is similar to PDP (Policy Decision Point) in Policy Framework [POLICY00]. 4.2.3 QLN (QoS Local Node) QLN is the edge router residing in the boundary of the DS domain. Figure 2 depicts that QLN could be part of ERC (Edge Router & Controller), or could reside in a component inside RAN (radio access network) such as BS (base station). QLN is like a J.-C. Chen, et al. Expires August 2006 [Page 11]
Internet Draft DSNP February 2006 wireless bandwidth broker which retains the local information of the resource in the local domain. However QLN does not interact with MS directly for QoS negotiation and signaling. In stead, this local information is provided to the QGS. QLN then performs traffic conditioning according to the instruction from the QGS. Therefore, it functions like PEP (Policy Enforcement Point) in Policy Framework [POLICY00]. In contrast to QGS, QLN handles the actual traffic thus it is in transport plane, similar to MG (Media Gateway) in MEGACO [MEGACO00]. Please note, the QGSs in domain 1 and domain 2 may contact with each other directly, or through a public QGS which may attach to the "Global IP Network" in Figure 2. Since QGS retains the global information of the whole administrative domain, dynamic service negotiation can be achieved easily and efficiently. The MS only needs to negotiate with the QGS, which makes the decision based on the up-to-date global information. Once it is done, the QGS will instruct the related QLNs how to condition the MS's traffic. Therefore, the MS can move freely inside the domain. How does the QGS allocate resource and reach the decision can be done in many different ways which have been proposed in literature. By separating control and transport, the architecture is also flexible, easy to add new services, easy to integrate with other network components, and easy to interoperate with legacy networks. One can also distribute the intelligence and functionality of QGS to all QLNs, which makes a different QoS architecture. The discussion of QoS architecture is outside the scope of this memo. We simply use the QoS architecture defined above to illustrate the applications of DSNP. 4.3 Distribution of QoS profile and Traffic Conditioning In wired network, it is easy to locate a user, therefore it is easy to locate the edge router that will need to condition the traffic for a specific user. In wireless networks, however, users can roam anywhere. Thus potentially all edge routers will need to know the QoS profile of a users. One straightforward solution is to let all edge routers in the domain maintain the QoS profiles of all users. Each time when service negotiation is done, the new SLS is broadcast to all edge routers. It is, however, inefficient to maintain the same copy of data in all edge routers. It causes unnecessary broadcast too. If the number of edge routers in the domain is huge, the data are replicated unnecessarily in many places. The database in each edge router will be huge too if there are many users in the domain. In addition, once a MS moves or J.-C. Chen, et al. Expires August 2006 [Page 12]
Internet Draft DSNP February 2006 changes its SLS, the same transaction for updating the database must be performed for all edge routers. Many edge routers may never have traffic coming from or going to the MS. It is desirable to maintain the QoS profiles of all users in the domain only in a central repository. Edge routers only keep the necessary data without maintaining the QoS profiles of all users in the domain. Referring to the QoS architecture presented in Section 4.2, the QGS of the domain retains the database of all users. Each time when the service negotiation is done, the QGS sends the new SLS of the user to potential QLNs only. The potential QLNs may be the neighboring QLNs of current serving QLN. Each time when the MS moves, the QGS can select the new set of potential QLNs, as that the QGS maintains the global information and is the decision maker. Therefore, the QoS profile of the MS can be distributed to the new QLN before the MS moves. Since everything is done by the network, the MS does not need to perform QoS-related signaling once the initial negotiation is done. It reduces the amount of QoS signaling messages, conserves MS's energy, and achieves fast handoff. 5. Example Applications 5.1 Initial QoS Negotiation When a MS is powered up, first it may need to perform registration and configuration with DHCP/DRCP to get an IP address. Before the MS sends actual traffic, it initiates the QoS signaling with the QGS if there is no service agreement or the MS wants to renegotiate it. The QGS may need to consult with AAA or other servers if necessary. Based on the interaction with other servers, the global information in QGS, service agreement, and other information such as mobility pattern, etc., the QGS will either admit or reject the QoS request. If the request is accepted, the SLS for the MS will be multicast to the potential QLNs. As discussed in Section 4.3, the potential set of QLNs may include current serving QLN and its neighboring QLNs. Figure 3 shows an example in that the MS uses DHCP to get an IP address for the subnet in the initial set-up. It then makes a QoS request for the list of available SLS. Based on the response, the MS negotiates with QGS for the SLS it wants. The QGS consults with AAA server, then makes the decision. Assuming that the QGS decides to offers certain kind of service to the MS. It sends the decision to the related QLNs so they can condition the MS's traffic accordingly. COPS [COPS00] or SNMP [SNMP99] can be used for the communication between QGS and QLNs. After receiving the SLS_NEGO_RESPONSE, the MS can send its actual traffic. J.-C. Chen, et al. Expires August 2006 [Page 13]
Internet Draft DSNP February 2006 DHCP AAA MS Server QGS Server QLNi | | | | | | DHCP DISCOVER | | | | |--------------->| | | | | DHCP OFFER | | | | |<---------------| | | | | DHCP REQUEST | | | | |--------------->| | | | | DHCP ACK | | | | |<---------------| | | | | | | | | | | | | | SLS_LIST_REQUEST | | | |---------------------------->| | | | | | | | SLS_LIST_RESPONSE | | | |<----------------------------| | | | | | | | SLS_NEGO_REQUEST | | | |---------------------------->| | | | | AAA REQUEST | | | |------------>| | | | AAA RESPOND | | | |<------------| | | | | | | | | | | UPDATE | | |------------------------->| | | ACK | | |<-------------------------| | | | | SLS_NEGO_RESPONSE | | |<----------------------------| | | | | | | | | | actual traffic | |<------------------------------------------------------>| | | * QLNi indicates the potential set of QLNs FIGURE 3: Example flow for initial set-up 5.2 Client Moves within the Same Domain J.-C. Chen, et al. Expires August 2006 [Page 14]
Internet Draft DSNP February 2006 When the MS is roaming inside the same administrative domain, i.e., the domain serving by the same QGS, the MS only needs to get a new IP address if changing subnet. It does not need to have any QoS signaling since the decision made by the QGS has been sent to all potential QLNs. As discussed in Section 4.3, the set of potential QLNs may be changed dynamically while the MS is moving. Thus the MS can transmit/receive traffic without initiating new QoS signaling while it is moving within the same administrative domain. Figure 4 is an example flow for moving within the same domain but the subnet is changed. DHCP MS Server QLNi QGS | DHCP DISCOVER | | | |---------------------->| | | | DHCP OFFER | | | |<----------------------| | | | DHCP REQUEST | | | |---------------------->| | | | DHCP ACK | | | |<----------------------| | | | | | | | | | | actual traffic | | |<-------------------------------------->| | | | | FIGURE 4: Example flow for moving within the same domain 5.3 Client Renegotiates SLS within the Same Domain Once the MS is up and the QoS negotiation is done, the MS is free to move within the same domain without any QoS signaling. As discussed before, however, the MS may want to change the SLS and renegotiate with the network for the service level. Figure 5 plots an example flow for this. It is similar to Figure 3 except that the MS has the IP address and the list of SLS already. AAA MS QGS Server QLNi | | | | | SLS_NEGO_REQUEST | | | |---------------------------->| | | | | AAA REQUEST | | | |------------>| | J.-C. Chen, et al. Expires August 2006 [Page 15]
Internet Draft DSNP February 2006 | | AAA RESPOND | | | |<------------| | | | | | | | | | | UPDATE | | |------------------------->| | | ACK | | |<-------------------------| | | | | SLS_NEGO_RESPONSE | | |<----------------------------| | | | | | | | | | actual traffic | |<------------------------------------------------------>| | | FIGURE 5: Example flow for renegotiating SLS within the same domain 5.4 Client Moves into a New Domain When the MS moves to a new administrative domain, it must initiate the QoS signaling with the new QGS. The new QGS may consult with the new AAA server, old AAA server, and the old QGS to decide whether it should admit or reject the QoS request. After that, it is similar to what described above. Figure 6 presents an example flow when the MS roams to a new domain. New DHCP New New Previous Previous New MS Server QGS AAA QGS AAA QLNi | | | | | | | | DHCP | | | | | | | DISCOVER| | | | | | |-------->| | | | | | | DHCP | | | | | | | OFFER | | | | | | |<--------| | | | | | | DHCP | | | | | | | REQUEST | | | | | | |-------->| | | | | | | DHCP | | | | | | | ACK | | | | | | |<--------| | | | | | | | | | | | | SLS_NEGO_REQUEST | | | | | |------------------>| | | | | J.-C. Chen, et al. Expires August 2006 [Page 16]
Internet Draft DSNP February 2006 | | AAA | | | | | | REQUEST | | | | | |-------->| | | | | | AAA REQUEST | | | | |------------------>| | | | | AAA RESPOND | | | | |<------------------| | | | AAA | | | | | RESPOND | | | | |<--------| | | | | | | | | | SLS_NEGO REQUEST | | | | |------------------>| | | | | SLS_NEGO_RESPONSE | | | | |<------------------| | | | | | | | | | | | | UPDATE | | |-------------------------------------->| | | ACK | | |<--------------------------------------| | SLS_NEGO_RESPONSE | | |<------------------| | | | | | | | actual traffic | |<--------------------------------------------------------->| | | FIGURE 6: Example flow for roaming to a new domain 6. DSNP Message Format All DSNP messages are sent in UDP/IP packets to special DSNP ports and are network byte ordered. The size of the fields is shown in braces. 6.1 SLS_LIST_REQUEST 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | J.-C. Chen, et al. Expires August 2006 [Page 17]
Internet Draft DSNP February 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The various fields are : FIELD OCTETS DESCRIPTION ----- ------ ----------- op 2 Message Opcode AttrMap 2 Attribute Map UID variable Universal identifier for the host. UIDlen 1 Length of the UID field 6.1.1 Opcode The opcode field has two octets. The first octet indicates which of the six messages described in section 3 is being transmitted or received. The possible values for the first octet are: Octet Value Message Type ----------- ------------ 0 0 0 0 0 0 0 0 SLS_LIST_REQUEST 0 0 0 0 0 0 0 1 SLS_LIST_RESPONSE 0 0 0 0 0 0 1 0 SLS_NEGO_REQUEST 0 0 0 0 0 0 1 1 SLS_NEGO_RESPONSE 0 0 0 0 0 1 0 0 SLS_STAT_REQUEST 0 0 0 0 0 1 0 1 SLS_STAT_RESPONSE Each type of DSNP message has associated sub-types. The second octet indicates the sub-type of the DSNP message. However, this message SLS_LIST_REQUEST has no sub-types. Hence the second octet will be assigned zero. The use of the second octet will be clear in the DSNP messages. 6.1.2 AttrMap The AttrMap field has two octets. This field is a bit map of the attributes the DSNP client is interested in negotiating with the DSNP server. In this version of DSNP, only the bits in the second octet are used in the bitmap. The first octet is reserved for future use. Bit Position Associated Attribute ------------- -------------------- 1 Scope 2 Flow specification 3 Traffic description J.-C. Chen, et al. Expires August 2006 [Page 18]
Internet Draft DSNP February 2006 4 Traffic guarantees 5 Service schedule 6 Unused 7 Unused 8 Unused For example, if the DSNP client sends bitmap 00001110 in the SLS_LIST_REQUEST message, it means that it is requesting only the flow specification, traffic description and traffic guarantees (and not the scope or the service schedule) of the various SLSs provided by the DSNP server. The field AttrMap is thus used to indicate the set of attributes that are negotiated between a DSNP client and the DSNP server. The second octet in opcode identifies which attribute of the set is being negotiated. 6.1.3 UID This filed is the universal identifier for the DSNP client. For example, this could be the IPv4 home address of the DSNP client, or the Network Access Identifier (NAI) [NAI99]. 6.2 SLS_LIST_RESPONSE The semantic content of SLS has associated attributes. The second octet in the opcode indicates which of the these attributes is being dealt by the message. So far, five attributes have been identified. They are : - Scope of the SLS - Flow specification - Traffic description and conformance testing - Performance guarantees - Service schedule The second octet indicates the sub-type within each of the above six messages. The possible values for the second octet are: Octet Value Sub-Type ------------ -------- 0 0 0 0 0 0 0 0 Initial message 0 0 0 0 0 0 0 1 Scope 0 0 0 0 0 0 1 0 Flow specification 0 0 0 0 0 0 1 1 Traffic description 0 0 0 0 0 1 0 0 Traffic guarantees 0 0 0 0 0 1 0 1 Service schedule There are five sub-types within the SLS_LIST_RESPONSE message. J.-C. Chen, et al. Expires August 2006 [Page 19]
Internet Draft DSNP February 2006 6.2.1 SLS_LIST_RESPONSE: Initial message 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SlsAvail(1) | SlsIndex(1) | SlsId(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This message is sent in response to the SLS_LIST_REQUEST message. All fields are in the same as in SLS_LIST_RESPONSE except that three new fields SlsAvail(1), SlsIndex(1) and SlsId(2) are included. 6.2.1.1 SlsAvail In response to the SLS_LIST_REQUEST message, the DSNP server could send a list of SLSs available to the DSNP client. The field SlsAvail indicates the total number of SLSs that are being sent. 6.2.1.2 SlsIndex SlsIndex indicates the number of the current SLS that is being sent. 6.2.1.3 SlsId SlsId is the identifier for the SLS that is being sent. In this message, the second octet of the field "op" is set to zero, indicating that, none of the SLS attributes are transmitted in that packet. Subsequent to the above SLS_LIST_RESPONSE message, the DSNP server sends additional SLS_LIST_RESPONSE messages that describe the attributes of the various SLSs offered. The DSNP server sends back only those attributes the DSNP client requested for using the "AttrMap" field of the SLS_LIST_REQUEST message. For each attribute that is begin sent, the second octet in the opcode is set appropriately. 6.2.2 SLS_LIST_RESPONSE: Sending the scope J.-C. Chen, et al. Expires August 2006 [Page 20]
Internet Draft DSNP February 2006 The scope of a SLS indicates the topology of the reservation with reference to the end-points of the traffic flow. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SlsAvail(1) | SlsIndex(1) | SlsId(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumIngRtr(2) | NumEgrRtr(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Ingress_list (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Egress_list (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All fields are common to the initial SLS_RESPONSE_MESSAGE sent but for the inclusion of the following fields: NumIngRtr(2), NumEgrRtr(2), Ingress_list(variable) and Egress_list(variable). The second octet in the opcode field is set to 00000001 to indicate the attribute scope is being sent in this message. 6.2.2.1 NumIngRtr This field indicates the number of Ingress routers associated with the scope. 6.2.2.2 NumEgrRtr This field indicates the number of Egress routers associated with the scope. 6.2.2.3 Ingress_list This field is the address list of the ingress routers in the scope. J.-C. Chen, et al. Expires August 2006 [Page 21]
Internet Draft DSNP February 2006 6.2.2.4 Egress_list This filed is the address list of the egress routers in the scope. 6.2.3 SLS_LIST_RESPONSE: Sending the flow Flow identification aims in creating an association between packets and SLSs. The Term "flow" refers to a stream of packets that are related. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SlsAvail(1) | SlsIndex(1) | SlsId(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (1) | FlowType(1) | NumFlows(1) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src IP address (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest IP address (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proto(1) | DS Byte (1) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source port number (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination port number (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Rest_flows(variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The second octet in the opcode is set to 00000010 to indicate that flow information about the SLS is being sent in the packet. The following fields are present in this message in addition to the fields already introduced: 6.2.3.1 Length This field indicates the length of the message in bytes. J.-C. Chen, et al. Expires August 2006 [Page 22]
Internet Draft DSNP February 2006 6.2.3.2 FlowType This field indicates whether the flow specification contains only one flow - Simple flow or multiple flows - Complex flow. The complex flow is the logical OR of the set of flows specified. Field FlowType ----- -------- 00000000 Simple flow 00000001 Complex flow 6.2.3.3 Numflows This field indicates the number of flows present in the specification. In the case of simple flow, this field will have a value 1, indicating only one flow is specified. In the case of a complex flow, this field will have a value equal to the number of flows. 6.2.3.4 Src Ip address This field indicates the source IP address associated with the flow. This could be a wild card entry or a IP address. 6.2.3.5 Dest Ip address This field gives the destination IP address associated with the flow. This could be a wild card entry or a IP address. 6.2.3.6 Proto This filed gives the protocol associated with the flow. For example, this could be either TCP or UDP. 6.2.3.7 DS Byte This filed gives the DS byte marking associated with the flow. Please note that this field indicates only the DSNP client-marking value. This is only for flow identification. The core routers do not take any routing decision based on this byte. 6.2.3.8 Source port number This field gives the source port number associated with the flow. This could be a wild card entry or a valid port number. J.-C. Chen, et al. Expires August 2006 [Page 23]
Internet Draft DSNP February 2006 6.2.3.9 Destination Port number This filed gives the destination port number associated with the flow. This could be a wild card entry or a valid port number. 6.2.3.10 Rest_flows This portion of the packet contains information about the additional flows in case a complex flow is defined. This includes fields from 6.2.3.4 to 6.2.3.9 for each of the remaining flows. 6.2.4 SLS_LIST_RESPONSE: Sending the traffic description and conformance parameters The traffic description aims to provide an effective description of the traffic relevant to the reservation. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SlsAvail(1) | SlsIndex(1) | SlsId(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SR (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSS (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PR (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSP (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAR (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | m (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The opcode field is set appropriately to indicate that traffic description parameters are being sent. The following fields J.-C. Chen, et al. Expires August 2006 [Page 24]
Internet Draft DSNP February 2006 are present, in addition to the fields already before: 6.2.4.1 SR This field indicates the Sustainable Rate in bit/s. 6.2.4.2 BSS This field gives the Bucket size in bytes for SR. 6.2.4.3 PR This field gives the peak rate of the traffic in bit/s. 6.2.4.4 BSP This field gives the bucket size in bytes for PR. 6.2.4.5 EAR This field gives the Expected Average Rate for the traffic in bit/s. 6.2.4.6 M This field gives the maximum allowed packet size in bytes. 6.2.4.7 m This field gives the minimum policed unit. 6.2.5 SLS_LIST_RESPONSE: Sending the performance guarantees The performance guarantee attributes describe the QoS parameters enjoyed by the flow specified by the flow id, with the specified scope and conforming to the specified traffic conformance attributes. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ J.-C. Chen, et al. Expires August 2006 [Page 25]
Internet Draft DSNP February 2006 | SlsAvail(1) | SlsIndex(1) | SlsId(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G| unused | QntDelayPercentile(3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntJitterPercentile (3) | QntMaxLoss(1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntMaxDelay (2) | QntMaxJitter(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntAveDelay (2) | QntAveJitter(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QltDelay (1) | QltJitter(1) | QltLoss (1) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The second byte in the opcode is set appropriately to indicate that performance guarantee attributes are being exchanged. The following fields are present in addition to the already explained fields : 6.2.5.1 G This field is only one bit wide and indicates whether the performance guarantee is qualitative or quantitative. '0' indicates qualitative and '1' indicates quantitative. 6.2.5.2 QntDelayPercentile This filed indicates the quantitative delay percentile. The first octet in this field indicates the percentile and the next two octets indicate the delay value in ms. 6.2.5.3 QntJitterPercentile This filed indicates the quantitative jitter percentile. The first octet in this field indicates the percentile and the next two octets indicate the jitter value in ms. 6.2.5.4 QntMaxLoss This field gives the quantitative maximum loss ratio of the packets. 6.2.5.5 QntMaxDelay This field gives the quantitative maximum delay in ms. 6.2.5.7 QntMaxJitter This field gives the quantitative maximum jitter in ms. J.-C. Chen, et al. Expires August 2006 [Page 26]
Internet Draft DSNP February 2006 6.2.5.8 QntAveDelay This field gives the quantitative average delay in ms. 6.2.5.9 QntAveJitter This field gives the quantitative average jitter in ms. 6.2.5.10 QltDelay This field gives the qualitative delay. The possible values are high, medium, low, very low. Field Qualitative Delay Value ----- ----------------------- 00000000 High 00000001 medium 00000010 low 00000011 very low 6.2.5.11 QltJitter This field gives the qualitative jitter. The possible values are high, medium, low, very low. Field Qualitative Jitter Value ----- ------------------------ 00000000 High 00000001 medium 00000010 low 00000011 very low 6.2.5.11 QltLoss This field gives the qualitative loss ratio. The possible values are high, medium, low, very low. Field Qualitative Loss ratio ----- ------------------------ 00000000 High 00000001 medium 00000010 low 00000011 very low J.-C. Chen, et al. Expires August 2006 [Page 27]
Internet Draft DSNP February 2006 6.2.6 SLS_LIST_RESPONSE: Sending the service schedule The servie schedule attributes provide information regarding the start and duration of the service. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SlsAvail(1) | SlsIndex(1) | SlsId(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SchType(1) | StrDay(1) | StartTime(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EndDay(1) | EndTime(2) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The second byte in the opcode is set appropriately to indicate that the service schedule attributes are being exchanged. The following fields are present in addition to the already explained : 6.2.6.1 SchType This field indicates the type of the schedule. The schedule could be Immediate and dynamic (like the telephone connections), or periodic or advance reservation with start date-time and end date-time specified. Field Schedule Type ----- -------------- 00000001 Immediate 00000010 Periodic 00000011 Advance reservation 6.2.6.2 StrDay This field indicates the starting day of the service. The values are offset from the current day. For example, a value of 0 would indicate the current day and a value of 1 would indicate the next day. J.-C. Chen, et al. Expires August 2006 [Page 28]
Internet Draft DSNP February 2006 6.2.6.3 StartTime This field indicates the start time of the service on the day specified in the StrDay field. 6.2.6.4 EndDay This field indicates the ending day of the service. The values are offset from the current day. 6.2.6.5 EndTime This field indicates the ending time of the service on the day specified in the EndDay field. 6.3 SLS_NEGO_REQUEST This message is used by the DSNP client to negotiate the QoS with a DSNP server. As in the SLS_LIST_RESPONSE message, the DSNP client starts by sending an initial SLS_NEGO_REQUEST message indicating the SLS attributes it wants to negotiate. Then subsequently, the DSNP client sends more messages with the actual SLS attributes. 6.3.1 SLS_NEGO_REQUEST: Initial message 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | options(variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode is set to "00000010" to indicate that it is a SLS_NEGO_REQUEST message. The second octet is set to "00000000" to indicate that this is the initial message in the negotiation. The AttrMap field is set suitably depending on the attributes the DSNP client wants to negotiate. J.-C. Chen, et al. Expires August 2006 [Page 29]
Internet Draft DSNP February 2006 6.3.2 SLS_NEGO_REQUEST: To negotiate the scope 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumIngRtr(2) | NumEgrRtr(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Ingress_list (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Egress_list (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode is set to 0000010 to indicate that it is a SLS_NEGO_REQUEST and the second octet is set to 0000001 to indicate that scope is being negotiated. The DSNP client sets appropriate values to other fields and sends the message to the DSNP server. 6.3.2 SLS_NEGO_REQUEST: To negotiate the flow 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (1) | FlowType(1) | NumFlows(1) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src IP address (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest IP address (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proto(1) | DS Byte (1) | | J.-C. Chen, et al. Expires August 2006 [Page 30]
Internet Draft DSNP February 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source port number (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination port number (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Information about rest of the flows (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode is set to 0000010 to indicate that it is a SLS_NEGO_REQUEST and the second octet is set to 0000010 to indicate that flow is being negotiated. The DSNP client sets appropriate values to other fields and sends the message to the DSNP server. 6.3.3 SLS_NEGO_REQUEST: To negotiate the traffic description and conformance parameters 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SR (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSS (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PR (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSP (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAR (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | m (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode is set to 0000010 to indicate that it is a SLS_NEGO_REQUEST and the second octet is set to 0000011 to indicate that traffic conformance parameters are being negotiated. The DSNP client sets appropriate values to other J.-C. Chen, et al. Expires August 2006 [Page 31]
Internet Draft DSNP February 2006 fields and sends the message to the DSNP server. 6.3.4 SLS_NEGO_REQUEST: To negotiate the performance guarantees 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G| unused | QntDelayPercentile(3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntJitterPercentile (3) | QntMaxLoss(1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntMaxDelay (2) | QntMaxJitter(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntAveDelay (2) | QntAveJitter(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QltDelay (1) | QltJitter(1) | QltLoss (1) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode is set to 0000010 to indicate that it is a SLS_NEGO_REQUEST and the second octet is set to 00000100 to indicate that performance guarantee parameters are being negotiated. The DSNP client sets appropriate values to other fields and sends the message to the DSNP server. 6.3.5 SLS_NEGO_REQUEST: To negotiate the service schedule 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SchType(1) | StrDay(1) | StartTime(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EndDay(1) | EndTime(2) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ J.-C. Chen, et al. Expires August 2006 [Page 32]
Internet Draft DSNP February 2006 The first octet in the opcode is set to 0000010 to indicate that it is a SLS_NEGO_REQUEST and the second octet is set to 00000101 to indicate that the service schedule is being negotiated. The DSNP client sets appropriate values to other fields and sends the message to the DSNP server. 6.4 SLS_NEGO_RESPONSE This message is sent by the DSNP server to the DSNP client in response to the SLS_NEGO_REQUEST. As in the SLS_NEGO_REQUEST message, the DSNP server starts by sending an initial SLS_NEGO_RESPONSE message indicating whether the request made by the DSNP client is accepted or not. If the request is accepted, the subsequent messages that follow confirm the parameters chose by the DSNP client. If the SLS_NEGO_REQUEST is not accepted, then the messages that follow tell the DSNP client the SLS that could be supported. 6.4.1 SLS_NEGO_RESPONSE: Initial message 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | options(variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode is set to 0000011 to indicate that it is a SLS_NEGO_RESPONSE and the second octet is set to 00000000 to indicate that the initial response to the SLS_NEGO_REQUEST is being sent. All the fields are same as explained before but for the "A" field. 6.4.1.1 A The A bit indicates whether the DSNP client's SLS request is accepted or not. If the A bit is set to '1', it means that the request was accepted. If the A bit is not set, it means J.-C. Chen, et al. Expires August 2006 [Page 33]
Internet Draft DSNP February 2006 that the request was not accepted. 6.4.2 SLS_NEGO_RESPONSE: Sending the scope attributes 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumIngRtr(2) | NumEgrRtr(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Ingress_list (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Egress_list (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode is set to 0000011 to indicate that it is a SLS_NEGO_RESPONSE and the second octet is set to 00000001 to indicate that the scope parameters are being sent. 6.4.3 SLS_NEGO_REQUEST: Sending the flow attributes 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (1) | FlowType(1) | NumFlows(1) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src IP address (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest IP address (4) | J.-C. Chen, et al. Expires August 2006 [Page 34]
Internet Draft DSNP February 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proto(1) | DS Byte (1) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source port number (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination port number (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Information about rest of the flows (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode is set to 0000011 to indicate that it is a SLS_NEGO_RESPONSE and the second octet is set to 00000010 to indicate that the flow parameters are being sent. 6.4.4 SLS_NEGO_REQUEST: Sending the traffic conformance and description attributes 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SR (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSS (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PR (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSP (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAR (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | m (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode is set to 0000011 to indicate that it is a SLS_NEGO_RESPONSE and the second octet is set to J.-C. Chen, et al. Expires August 2006 [Page 35]
Internet Draft DSNP February 2006 00000011 to indicate that the traffic conformance and description parameters are being sent. 6.4.5 SLS_NEGO_REQUEST: Sending the performance guarantee attributes 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G| unused | QntDelayPercentile(3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntJitterPercentile (3) | QntMaxLoss(1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntMaxDelay (2) | QntMaxJitter(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntAveDelay (2) | QntAveJitter(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QltDelay (1) | QltJitter(1) | QltLoss (1) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode is set to 0000011 to indicate that it is a SLS_NEGO_RESPONSE and the second octet is set to 00000100 to indicate that the performance guarantee attributes are being sent. 6.4.6 SLS_NEGO_REQUEST: Sending the service schedule attributes 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | AttrMap(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SchType(1) | StrDay(1) | StartTime(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ J.-C. Chen, et al. Expires August 2006 [Page 36]
Internet Draft DSNP February 2006 | EndDay(1) | EndTime(2) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode is set to 0000011 to indicate that it is a SLS_NEGO_RESPONSE and the second octet is set to 00000101 to indicate that the service schedule attributes are being sent. 6.5 SLS_STAT_REQUEST 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode field is set to 00000100 to indicate that this is a SLS_STAT_REQUEST message. The second octet is set to zero. Unlike other DSNP messages seen so far, only one SLS_STAT_REQUEST message is sent. 6.6 SLS_STAT_RESPONSE 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(2) | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UIDlen(1) | UID(variable) | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | QntDelayPercentile(3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntJitterPercentile (3) | QntMaxLoss(1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntMaxDelay (2) | QntMaxJitter(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QntAveDelay (2) | QntAveJitter(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OctSent(4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OctRcvd (4) | J.-C. Chen, et al. Expires August 2006 [Page 37]
Internet Draft DSNP February 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet in the opcode field is set to 00000101 to indicate that this is a SLS_STAT_RESPONSE message. The second octet is set to zero. Like SLS_STAT_REQUEST message, only one SLS_STAT_RESPONSE is sent. The following fields are unique to SLS_STAT_RESPONSE message: 6.6.1 OctSent This field indicates the total number of octets sent from the DSNP client. 6.6.2 OctRcvd This field indicates the total number of octets forwarded to the DSNP client. 7. Acknowledgments The authors wish to acknowledge the contributions of other members of the ITSUMO (Internet Technologies Supporting Universal Mobile Operation) team from Telcordia Technologies and Toshiba America Research Incorporated. (TM): ITSUMO (Internet Technology Supporting Universal Mobile Operation) is a trademark of Telcordia. It is a joint research project of Telcordia Technologies and Toshiba America Research Inc. (TARI). It envisions an end-to-end wireless/wireline IP platform for supporting real-time and non-real-time multimedia services in the future. Its goal is to use IP and third generation wireless technologies to design a wireless platform that allows mobile users to access multimedia services on a next generation Internet. In Japanese, ITSUMO means all the time, anytime. 8. References [COPS00] D. Durham, et al., "The COPS (Common Open Policy Service) Protocol", IETF RFC 2748, Jan. 2000. [DHCP97] R. Droms, "Dynamic Host Configuration Protocol", IETF RFC 2131, Mar. 1997. [DIFF01] D. Grossman, "New Terminology for Diffserv", IETF Internet Draft, <draft-ietf-diffserv-new-terms-04.txt>, work in progress, Mar. 2001. [DIFF98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and J.-C. Chen, et al. Expires August 2006 [Page 38]
Internet Draft DSNP February 2006 W. Weiss, "An Architecture for Differentiated Services", IETF RFC 2475, Dec. 1998. [DRCP00] A. McAuley, S. Das, S. Madhani, S. Baba, and Y. Shobatake, "Dynamic Registration and Configuration Protocol (DRCP)", IETF Internet Draft, <draft-itsumo-drcp-01.txt>, work in progress, Jul. 2000. [IMT97] ITU-R Rec. M.687-2, "International Mobile Telecommunications-2000 (IMT-2000)", 1997. [INT94] R. Braden, D. Clark, and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", IETF RFC 1633, Jun. 1994. [ITSUMO00] ITSUMO Group, "Benchmarking of ITSUMO's All IP Wireless Architecture", mwif2000.028, Jan. 28, 2000. [ITSUMO99] ITSUMO Group, "Evolution of Wireless Telephony Towards Voice over 3G-IP", 3GPP2-P00-19990824-010, Aug. 23, 1999. [MEGACO00] F. Cuervo, et al., "Megaco Protocol Version 1.0", IETF RFC 3015, Nov. 2000. [NAI99] B. Aboba and M. Beadles, "The Network Access Identifier", IETF RFC 2486, Jan. 1999. [POLICY00] R. Yavatkar, et al., "A Framework for Policy-based Admission Control", IETF RFC 2753, Jan. 2000. [SNMP99] J. Case, et al., "Introduction to Version 3 of the Internet-standard Network Management Framework", IETF RFC 2570, Apr. 1999. 9. Authors' Addresses Jyh-Cheng Chen Department of Computer Science National Tsing Hua University Hsinchu 300, Taiwan Phone: +886-3-574-2961 Email: jcchen@cs.nthu.edu.tw Anthony J. McAuley Telcordia Technologies One Telcordia Drive, RRC-1A225 Piscataway, NJ 08854-4157 Phone: +1-732-699-2431 J.-C. Chen, et al. Expires August 2006 [Page 39]
Internet Draft DSNP February 2006 Email: mcauley@research.telcordia.com Venkatesh Sarangan Department of Computer Science Oklahoma State University 219 MSCS Stillwater, OK 74078 Phone: +1-405-744-5672 Email: saranga@cs.okstate.edu Shinichi Baba PC & Network Company Toshiba Corporation Shibaura 1-1-1, Minato-Ku Tokyo 105-8001, Japan Phone: +81-3-3457-2583 Email: shinichi1.baba@toshiba.co.jp Yoshihiro Ohba Toshiba America Research, Inc. One Telcordia Drive Piscataway, NJ NJ 08854-4151 Email: yohba@tari.toshiba.com Full Copyright Statement "Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." J.-C. Chen, et al. Expires August 2006 [Page 40]