RE: [NSIS] Adding Binding_Code to QoS NSLP BOUND_SESSION_ID object

Hi 

My initial thought is that 8-bit seems to be sufficient to cover the few
atomic actions we are currently talking about, as well as their possible
combinations. So the rest of the space may be left for whatever other
extensions. 

But I don't have strong opinion over whether 8 bit or 16 bit should be
chosen at this point. 

Thanks.

Charles 

> -----Original Message-----
> From: jmanner@cs.helsinki.fi [mailto:jmanner@cs.helsinki.fi] 
> Sent: Thursday, November 10, 2005 8:10 PM
> To: Hong.Cheng@sg.panasonic.com; charles@cs.columbia.edu; 
> nsis@ietf.org
> Subject: RE: [NSIS] Adding Binding_Code to QoS NSLP 
> BOUND_SESSION_ID object
> 
> 
> 
> Hi,
> 
> I also supported this in my presentation today. We'll include 
> it in the next version of the draft. Yet, I'd like to make a 
> slight change to it. Allocate more than 8-bits for the code, 
> eg. 16 bits. Why only use 8 bits and leave 24 bits unused?
> 
> Jukka
> 
> On 11/11/2005, "Cheng Hong" <Hong.Cheng@sg.panasonic.com> wrote:
> > Hi Charles,
> > 
> > I think this code is a good idea. It is especially useful when the 
> > aggregation and bi-direction binding exists over the same section.
> > 
> > cheers
> > 
> > Cheng Hong
> > 
> > > -----Original Message-----
> > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On
> > > Behalf Of Charles Shen
> > > Sent: Thursday, November 10, 2005 4:07 AM
> > > To: nsis@ietf.org
> > > Subject: [NSIS] Adding Binding_Code to QoS NSLP 
> > > BOUND_SESSION_ID object 
> > > 
> > > Hi all,
> > > 
> > > As described in the NSIS Operation over IP tunnels draft
> > > (http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-01
> > > .txt), the BOUND_SESSION_ID object may be used to carry the 
> > > dependency of the tunnel session and the corresponding e2e 
> > > session. The BOUND_SESSION_ID object defined in QoS NSLP 
> > > draft however does not indicate the nature of session 
> > > dependency. It may also be used for bi-directional flows or 
> > > flow aggregation etc. The currently defined general rule to 
> > > process a message with a BOUND_SESSION_ID object (e.g. a QNE 
> > > MUST copy the BOUND_SESSION_ID object into all messages it 
> > > sends for the same session.) might not fit in the tunneling 
> > > context. For NSIS-tunnel operation, the dependency is 
> > > maintained by  tunnel endpoints and should not be propagated 
> > > further outside the tunnel.  
> > > 
> > > Therefore we would like to know whether the WG thinks it is a
> > > good idea to add a Binding_Code field to the current 
> > > BOUND_SESSION_ID object (the format is attached at the end of 
> > > this email for reference).
> > > 
> > > Thanks!
> > > 
> > > Charles
> > > 
> > > 
> > > P.s. BOUND_SESSION_ID object with Binding_Code:
> > > 
> > >    Type: BOUND_SESSION_ID
> > > 
> > >    Length: Fixed - 5 32-bit words
> > > 
> > >    Value: contains an 8-bit Binding_Code that indicates 
> the nature of
> > >    binding.  The rest specifies the Session ID of the session
> > > that must
> > >    be bound to the session associated with the message 
> carrying this
> > >    object.
> > > 
> > >       
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >       |                  RESERVED                     |  
> > > Binding_Code |
> > >       
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >       |                                                       
> > >         |
> > >       +                                                       
> > >         +
> > >       |                                                       
> > >         |
> > >       +                          Session ID                   
> > >         +
> > >       |                                                       
> > >         |
> > >       +                                                       
> > >         +
> > >       |                                                       
> > >         |
> > >       
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > 
> > > 
> > > 
> > >    Figure 1: BOUND_SESSION_ID Object
> > > 
> > >    Currently defined Binding_Codes are:
> > > 
> > >    o  0x01 - Tunnel and end-to-end sessions
> > >    o  0x02 - Bi-directional sessions
> > >    o  0x03 - Aggregate sessions
> > >    o  0x04 - Dependent sessions (one session is alive only if
> > > the other
> > >       session is also alive)
> > > 
> > >    More binding codes maybe defined based on the above four atomic
> > >    binding actions.  It is not clear whether we need to allow
> > > more than
> > >    one SESSION ID in the binding object.
> > > 
> > > A BOUND_SESSION_ID object carrying the code 0x01 is called a
> > > tunnel BOUND_SESSION_ID object in the tunneling draft.
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > > 
> > 
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis