Internet Draft                                                       
                                                         S. M. Shahrier  
                                                         K. M. Shaheen 
                                                                        
   Document: draft-shahrier-nsis-framework-01.txt          InterDigital 
   Expires:                                               December 2002 
 
                  A Framework for Bi-Directional QoS Signaling 
 
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 obsolete 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. 
    
Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in RFC-2119 [1]. 
 
Abstract 
 
This Internet Draft describes the end-to-end signaling architecture and 
framework model for transmitting packets through a series of 
heterogeneous networks. The Next-Steps-In-Signaling (NSIS) Working 
Group is already working on defining a set of requirements for the QoS 
signaling protocol [1]. This document is the follow on to the 
requirements draft, and the precursor to any solutions document. It 
outlines a   framework for transporting end-to-end QoS parameters, 
initiated and maintained by the ôOriginatorö of the service. 
 
This draft elaborates on the requirements draft.  It defines more 
precisely the scope of NSIS for end-to-end packet flows, in terms of  
QoS Signaling, where the resource reservations for the service are  
initiated by the ôOriginatorö end point and whether this service is bi-
directional or unidirectional (i.e., receive-only or send-only). The 
draft is fully backward compatible; it requires no changes to the 
existing QoS signaling protocols or procedures. It applysapplies 
     
   Shahrier     Standard Track û Expires December 2002               1 
             A Framework for Bi-Directional QoS Signaling    June 2002 
    
generic messages to transport  the information needed to establish the 
desired QoS  for traffic flows in either one or both directions. This 
document can be used as the guideline for a prospective solution to the 
QoS signaling problem.  
 
 
  1. Introduction 
    
With the current evolution toward wireless data, wireless internet, and 
wireless multimedia applications such as Voice over IP (VoIP), video 
conferencing, and Video telephony, performance requirements similar to 
those of existing circuit switched or voice based wireless systems are 
essential.  Among these performance requirements are call setup time, 
delay, reliability, and Quality of Service (QoS).  Ensuring QoS, 
providing faster call setup time, while reducing the number of QoS 
control messages across the network, is the subject of this note.  
 
This draft introduces the concept of and the architectural framework for 
bi-directional  resource  reservation  signaling  protocol  for  both 
Controlled-Load and Guaranteed QoS control services.  The existing RSVP 
signaling allows for uni-directional resource reservations only in the 
ôsendö direction, while the proposed signaling protocol generalizes the
process by allowing simultaneous bi-directional (ôsendö and ôreceiveö) 
resource reservations on each hop.  The proposed signaling protocol is 
most suitable for applications in which the ôOriginatorö of a service is 
solely responsible for making the necessary reservations, authentication 
and their cost.   
 
While it is important and necessary to consider QoS from an end-to-end 
prospective, the NSIS Working Group shall restrict the scope of its 
activities to the transport and signaling of QoS packets in the NSIS 
domain only.  The objective of this draft is to provide an overview of 
the architecture and signaling within the NSIS network. 
 
2. Bi-Directional Signaling Protocol Model 
 
The underlying assumption is that the ôOriginatorö of a multimedia 
session negotiates the media information with the ôTerminatedö side.  
Both sides have to agree on the means by which the session will be 
carried, including the type of service (audio, video, or/and text), 
codec information, bit rate for both directions, port numbers, etc.  In 
order to allocate resources for the negotiated session within the NSIS 
network, the originator of the multimedia session invokes reservation 
procedures using the proposed bi-directional signaling protocol. The Bi-
directional signaling protocol carries the QoS control objects that 
specify the QoS necessary to carry the traffic in both directions. 
 
     
   Shahrier     Standard Track - Expires December 2002               2 
            A Framework for Bi-Directional QoS Signaling    June 2002  
    
 
2.1 Summary of Bi-directional Signaling Protocol 
 
  The operation of the bi-directional signaling proceeds as follows: 
 
     1) The ôOriginatorö provides the QoS parameters describing the 
       nature of the traffic (including the transaction Type; uni-
       directional or bi-directional).  This information is used to 
       construct the various objects of the message format.  
      
     2) The ôOriginatorö sends an  initial ôSetupö message to the 
       ôTerminatedö end point and waits for a response.   
 
     3) The initial ôSetupö message follows a predetermined route to the 
       ôTerminatedö end point where it requests the assignment of 
       resources  needed to carry the desired traffic flows.  
 
     4) In each hop, the router updates certain fields that indicate 
       whether the requested resources are available and forwards the 
       updated initial ôSetupö message to the next hop.  
 
     5) At the ôTerminatedö end point, the updated ôSetupö message is 
       examined.  If  the  resource  allocation  is  satisfactory,  a  
       ôTerminatedö end point wishing to complete the transaction 
       replies to the ôSetupö message with an ôAcceptanceö message.   
 
     6) The ôAcceptanceö message follows the same path that carried the 
       ôSetupö  message  from  the  ôOriginatorö  end  point.    The 
       ôAcceptanceö message carries the final resources that are needed 
       to be installed in the various hops along the signaling route. 
 
     7) At each hop ,hop, the ôAcceptanceö message is processed to 
       establish the required resources and then forwarded to the next 
       hop toward the ôOriginatorö end point. 
 
     8)  At the ôOriginatorö end point, the final ôAcceptanceö message 
       is processed. If successful, the ôOriginatorö end point replies 
       with a ôConfirmationö message back to the ôTerminatedö end point 
       to acknowledge the establishment of the traffic path. 
 
     9) During the session, the ôOriginatorö end point is responsible 
       for maintaining the resources. 
 
     10)If either side decides to terminate the session, a ôDisconnectö 
       message is sent by the side terminating the resources along the 
       established route.    
     
   Shahrier     Standard Track - Expires December 2002               3 
             A Framework for Bi-Directional QoS Signaling    June 2002  
    
 
3. Signaling Diagrams 
 
This section shows, the signaling diagrams for the Bi-directional 
signaling protocol. The diagrams show that the proposed protocol is 
backward compatible with existing QoS signaling protocols. 
 
3.1 Connection Setup (Accepted) 
 
 
Originator                           IP NETWORK                         Terminated 
|                         |                         |                         | 
|  Setup(Type,QoS Param)  | Setup(Type,QoS Param)   | Setup(Type,QoS Param)   | 
|------------------------>|--------------------- -->|------------------------>| 
|                         |                         |                         | 
|                         |                         |                         | 
|  Accept(Type,QoS Param) |  Accept(Type,QoS Param) |  Accept(Type,QoS Param) | 
|<------------------------|<------------------------|<------------------------| 
|                         |                         |                         | 
|                         |                         |                         | 
|      Confirm            |         Confirm         |           Confirm       |
|------------------------>|------------------------>|------------------------>| 
|                         |                         |                         | 
 
 
3.2 Connection Setup (Rejected) 
 
 
Originator                           IP NETWORK                         Terminated 
|                         |                         |                         | 
|  Setup(Type,QoS Param)  | Setup(Type,QoS Param)   | Setup(Type,QoS Param)   | 
|------------------------>|--------------------- -->|------------------------>| 
|                         |                         |                         | 
|                         |                         |                         | 
|  Denied(Type,QoS Param) |  Denied(Type,QoS Param) |  Denied(Type,QoS Param) | 
|<------------------------|<------------------------|<------------------------| 
|                         |                         |                         | 
|                         |                         |                         | 
|         Confirm         |         Confirm         |         Confirm         |
|------------------------>|------------------------>|------------------------>| 
|                         |                         |                         | 
 
 
3.3 Connection Teardown 
 
     
   Shahrier     Standard Track - Expires December 2002               4 
             A Framework for Bi-Directional QoS Signaling    June 2002 
    
 
Originator                        IP NETWORK                            Terminated 
|                         |                         |                         | 
|        Disconnect       |       Disconnect        |         Disconnect      | 
|------------------------>|------------------------>|------------------------>| 
|                         |                         |                         | 
 
 
 
 
4. References 
 
   [1] Brunner, J., "Requirements for QoS Signaling Protocolsö, draft-
                     nsis-req-02.txt (work in progress), may 2002. 
    
 
 
5. Contact Information 
    
   Sharif M. Shahrier 
   InterDigital  
   781 Third Ave.               Phone: 1-610-878-7878 
   King of Prussia, PA. USA     Email: sharif.shahrier@interdigital.com 
    
   Kamel M. Shaheen 
   InterDigital  
   781 Third Ave.               Phone: 1-610-878-7878 
   King of Prussia, PA. USA     Email: kamel.shaheen@interdigital.com 
    
    
    
    
    
     
   Shahrier     Standard Track - Expires December 2002               5