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

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