Subject: RE: [NSIS] Requirement Section 5.3.2

From: [email-masked]
Date: Tue, 12 Mar 2002 14:03:13 +0100

Hi all,

I agree with Georgis reasoning.
If the NSIS protocol is focusing on bearers only, then it should have no
knowledge on services like, e.g. "video calls", but only on bearers having
some properties (bandwidth, delay, etc.), no matter what those bearers are
carrying, no matter for which services they are being used.
If you "purchase a video call for one hour duration", then the duration of
the *service* is one hour, and that's what you are paying for.

Best regards

     Juan Carlos

"Georgios Karagiannis (ELN)" <[email-masked]>
@ietf.org on 12/03/2002 10:54:02

Sent by:  [email-masked]

To:   "'Schneider, Marco'" <[email-masked]>, "'Steven Berson'"
      <[email-masked]>
cc:   "[email-masked]'" <[email-masked]>, [email-masked]
Subject:  RE: [NSIS] Requirement Section 5.3.2

Hi Marco

I do not know if I understand your point.
You can achieve the same operation by just explicitly
releasing the resources after one hour!
Only the end host has to know that the resources
will be kept for one hour.

In this case the network will not have to store for each flow
the reservation time. If the network would do that
then we will have a very non-scalable solution, i.e.,
increasing number of users the number of reservation
lifetime states are increased.

However, I think Steve Berson had a reasonable solution on this:
Emphasise in the requirement that advance reservations are not
required, but if you wanted advance reservations, then
reservation duration seems like a useful thing to have.

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: maandag 11 maart 2002 19:30
To: 'Georgios Karagiannis (ELN)'; 'Steven Berson'
Cc: [email-masked]'; [email-masked]
Subject: RE: [NSIS] Requirement Section 5.3.2

Hi Georgios,

I think the ability to control reservation life-times may be a useful
capability. Say for instance that I purchase a video call for one hour
duration. NSIS should support the ability of the network to end the
associated reservation after one hour. While this does not absolutely
necessitate making the reservation lifetime an explicit part of the
reservation request semantics, I think it would make sense to do so in
support of this situation.

Marco

> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: Friday, March 08, 2002 1:36 PM
> To: 'Steven Berson'
> Cc: [email-masked]'; [email-masked]
> Subject: RE: [NSIS] Requirement Section 5.3.2
>
>
> Hi Steve
>
> The associated motivation given for this requirement
> in the NSIS WG draft is that "allows reducing the reservation
> update frequency in case of soft state based signaling." (from draft)
>
> Therefore, I thought that it was related to the soft-state refresh
> timer. Do you have another motivation to keep this requirement.
>
> Best regards,
> Georgios
>
>
> -----Original Message-----
> From: Steven Berson [mailto:[email-masked]]
> Sent: vrijdag 8 maart 2002 20:30
> To: Georgios Karagiannis (ELN)
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [NSIS] Requirement Section 5.3.2
>
>
> Georgios,
>
> I am not sure if it is a good idea to support reservation life-times,
> but at this time, it does not seem like a good idea to preclude it.
> Also, the reservation life-time is not necessarily related to the
> soft-state refresh timer.
>
> Steve
>
> On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote:
>
> > Hi Marcus
> >
> > Regarding requirement in Section 5.3.2:
> >
> > "Ability to signal life-time of a reservation":
> >
> > The problem that I have with this requirement is that it will
> > increase the complexity of the functionality related to the soft
> > state (refresh) principle in a node.
> > Please note that the soft state refresh principle is used
> > to somehow solve unexpected changes in the network, e.g.,
> route changes
> > that are independent of the lifetime of a reservation.
> > Therefore, I do not think that the lifetime of the reservation
> > should affect the duration of the soft state refresh.
> > Please remove it!
> >
> > Best regards,
> > Georgios
> >
> >
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Tricci So <[email-masked]>
Date: Tue, 12 Mar 2002 06:53:19 -0800

Hi all,

Since I can't attend the next NSIS meeting, I thought that it may be a good
idea to get your input on my draft regarding the scope of the NSIS work over
the mailing list.   Also, please forgive me that I haven't been following the
mailing list discussion 100% due to the volume of the emails and my work
load.  I hope that I am not repeating something that have been agreed.

Anyway, looking forward to hear your view on this subject.  I have also
attached my draft to this email.  Please check it out....

Tricci

NSIS Working Group                                    Tricci So  
Internet Draft                                        Caspian Networks 
Expiration Date: Sept 2002       
 
                      NSIS Scope Recommendations 
                      Draft-so-nsis-scope-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 
    
Abstract 
 
   The intent of this draft is to recommend the scope of the work for 
   the NSIS working group so that the team can focus on the key work 
   signaling issues that need to be resolved and to develop the 
   solutions promptly.  
    
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. 

So                      Expires September 2002                [Page 1] 


Internet Draft        draft-so-nsis-scope-00.txt        September 2002 

                            Table Of Contents 

   1. Motivations....................................................3 

   2. Modified SIP Network Architecture..............................4 

   3. Concepts of Bearer Control Signaling vs. Call Control Signaling5 

   4. Rationales.....................................................5 

   5. Security Considerations........................................5 

   6. Recommendation.................................................5 

   7. IANA Consideration.............................................6 

   8. References.....................................................6 

   9. Authors' Addresses.............................................6 

So                      Expires September 2002                [Page 2] 


Internet Draft        draft-so-nsis-scope-00.txt        September 2002 

1. Motivations 
    
   As indicated in the current working group charter, the objective of 
   the NSIS work is to develop a simplified solution to signal QoS 
   requirements for variety types of multimedia services over the 
   Internet.   
    
   At the moment, the discussions so far seem to look into all aspects 
   of the signaling issues that were encountered in the network.  In 
   addition, there is no specific network model that can be referred 
   by the NSIS working group to focus on the signaling requirements 
   discussion at different network levels.  Hence, this draft brings 
   forward a network model that was derived from the Session 
   Initiation Protocol (SIP) [RFC 2543] network architecture so that 
   the NSIS working group can use it as the base to identify the scope 
   of the working area and to build the consensus on the requirements 
   as well as the solutions.  However, it is not the objective of this 
   draft to propose the following network model as the NSIS signaling 
   reference model.  
    
   The intents of this draft are:  
   -
    to identify the two main streams of control signaling in a 
     telecommunication network to support multi-media services - i.e. 
     call control signaling and bearer control signaling. 
   -
    to recommend the focus on the bearer control signaling by the 
     NSIS WG since it is more related to use of the Internet as the 
     transport medium to support the requested QoS transport 
     characteristic, and leave the call control signaling to other 
     consortium to tackle since it is more related to the network 
     services and policy control.  

So                      Expires September 2002                [Page 3] 


Internet Draft        draft-so-nsis-scope-00.txt        September 2002 

2. Modified SIP Network Architecture   
    
   The following describes the network model that is derived from the 
   SIP network architecture that depicts the separation of the call 
   control signaling from the bearer control signaling to support 
   multi-media services.   
    
           ---------------        -----------------          
           | Applications|        |  Applications |                
           |  or         |<-SIP-> |   or          |          
           |  Services   |        |  Services     |          
           ---------------        -----------------         ^ 
                  ^                      ^                  | 
                  |                      |                  | 
                 SIP                    SIP                Call 
                  |                      |                Control 
                  v                      v               Signaling     
             ------------            ------------           | 
             | Media    |            |  Media   |           | 
             | Gateway  | <-SIP-T->  | Gateway  |           | 
             |Controller|            |Controller|           |    
             ------------            ------------           | 
       e.g.      ^  ^                   ^   ^  e.g          | 
       SS7      /   | e.g.         e.g. |    \ MGCP         |  
       ----------   | MGCP        H.248 |    ---------      | 
       |PSTN or |   |                   |    |  IAD  |      |     
       | PLMN   |   |                   |    ---------      | 
       ----------   |                   |                   v 
    =============== v ================= v ======================= 
              ----------             ----------              
           -  |  Media | ----------  | Media  | -\           
       ---/   | Gateway| <- e.g. ->  |Gateway |   \-----\           
      /       |        | RSVP, RTP,  |        |         | 
      |       ---------- Diffserv    ----------         | 
      |                                                 |              
      |         <------- Bear Control ------>           | 
      |                   Signaling                     | 
      \                                                 / 
       \                                               / 
        ----------------------------------------------- 
                   Private and/or Public IP Network 
    
   where:  
   Diffserv - Differentiated Services  
   IAD      - Integrated Access Devices 
   MGCP     - Media Gateway Control Protocol 
   PLMN     - Public Land Mobile Network  
   PSTN     - Public Switching Trunking Network  
   RSVP     - Resource ReSerVation Protocol 
   RTP      - Realtime Transport Protocol 
   SIP      - Session Initiation Protocol 
   SS7      - Signaling System 7 
 
So                      Expires September 2002                [Page 4] 


Internet Draft        draft-so-nsis-scope-00.txt        September 2002 

3. Concepts of Bearer Control Signaling vs. Call Control Signaling 
    
   The purpose of Bearer Control Signaling is to communicate QoS 
   information to the transport network so that the network can make 
   the necessary arrangements and provide to the requesting 
   application a bearer channel/path with the described transport 
   characteristic. Bearer control signaling does not necessarily 
   traverse the transport network end-to-end uninterrupted, but at 
   certain intermediary nodes is elevated and interpreted. These 
   intermediate nodes need therefore to understand the signaling 
   content and make the necessary actions in response to it.  
    
   The Call Control signaling could logically be modeled after the 
   manner of an end-to-end application layer protocol specifically 
   tailored for the service at hand. For example, SS7 in PSTN is 
   geared towards providing voice grade services on demand and 
   providing policy control.  The span of the call control signaling 
   is likely end-to-end.  

4. Rationales 
    
   Although there is a strong desire from the service providers to 
   consolidate their networks to support multi-media services, their 
   main intent is to converge the transport infrastructure and not the 
   services infrastructure.  It is because different types of services 
   require different platforms to manage the services, e.g. SS7 IN 
   services for PSTN, of which those infrastructure takes years to 
   build and to mature.   
    
   It is extremely economical for the service providers to be able to 
   migrate their multi-media traffic from the multi-services network 
   onto the Internet along with their data traffic.  It also opens the 
   opportunity for the service providers to offer new services for the 
   emerging new applications, e.g. wireless applications and DSL etc.  
    
   Hence, it is important for the NSIS WG to develop a generic bearer 
   control signaling mechanism to identify the certain transport 
   characteristic when establishing the bearer path to carry 
   multimedia traffic.  

5. Security Considerations 
    
   N/A 

6. Recommendation 
    
   The intent of this draft is to recommend the scope that the NSIS WG 
   should focus to design a simplified signaling mechanism to provide 
   QoS support for multimedia services over Internet.   
 
So                      Expires September 2002                [Page 5] 


Internet Draft        draft-so-nsis-scope-00.txt        September 2002 

   It is important for the NSIS WG to focus on the bearer control 
   signaling aspect so that the Internet can be used to provide high 
   quality transport of the multimedia traffic.  

7. IANA Consideration  
    
   N/A 

8. References 
    
   IETF RFC  
    
   [Sig-Arch]     Menelaos K. Perdikeas, Iakovos S. Venieris, 
                  "Signaling and Service Integration between Internet 
                  and PSTN" 
    
   [RFC2543]      M. Handley, H.Schulzrinne, E. Schooler, J. 
                  Rosenberg, "Session Initiation Protocol", RFC 2543, 
                  March 1999. 

9. Authors' Addresses 
    
   Tricci So  
   Caspian Networks 
   170 Baytech Drive 
   San Jose, CA, USA 95134 
   Email: 
   [email-masked] 

    

So                      Expires September 2002                [Page 6]