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

From: "Charles Shen" <[email-masked]>
Date: Wed, 9 Nov 2005 15:06:47 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Fri, 11 Nov 2005 09:44:28 +0100

Hi Charles,

> is attached at the end of this email for reference).

Yes, I think its a good idea to have that, so I support this proposal.

>    o  0x01 - Tunnel and end-to-end sessions

If the same session is tunneled several times
(and nested) then a tunnel session is bound to another
tunnel session rather than to an end-to-end session.
I don't think that we need a different codepoint for that,
but otherwise the description may be interpreted to limit
the use of 0x01 for the particular case of tunneling a normal
end-to-end session.

>    o  0x02 - Bi-directional sessions

Does 0x02 include the semantics of 0x04? :-)

>    o  0x04 - Dependent sessions (one session is alive only if the other

Hmm, 0x04 seems obvious, but may have issues. I've thought several
times about interdepencies of flows within a session or handover
of multiple sessions and came to the conclusion that this is a
good case to apply the end-to-end argument.
That means: instead of letting the network
know any logical relations between flows (or sessions in this context)
the network should not be aware of them. Why? Because in case of
a failure of one flow (or session) you must specify how the network
reacts in this case. Usually there are too many options that
applications may require so that it's not good (because too complex)
to put that intelligence into the network to cover every possible
behavior desired by various applications. Applying the e2e would
lead to the conclusion that every application should
decide by itself which flows/sessions should be maintained is case
some flows/sessions are affected by failures.

Now 0x04 is a simple AND relationship between sessions, but
then we have to specify exactly how the nodes behave in case
one session is affected by a failure: is the other session
explicitly torn down then (which is implied by the predicate
that 0x04 defines)? Or is it only a hint for the network that
sessions are dependent, but no special action is taken?

Regards,
 Roland