[NSIS] Questions about draft-ietf-nsis-req-09.txt

Vishal Zinjuvadia <vzinjuvadia@yahoo.com> Sun, 17 August 2003 17:53 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16849 for <nsis-archive@odin.ietf.org>; Sun, 17 Aug 2003 13:53:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oRiA-000823-GU for nsis-archive@odin.ietf.org; Sun, 17 Aug 2003 13:53:02 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7HHr2up030874 for nsis-archive@odin.ietf.org; Sun, 17 Aug 2003 13:53:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oRi9-00081r-HF; Sun, 17 Aug 2003 13:53:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oRhC-00081G-2I for nsis@optimus.ietf.org; Sun, 17 Aug 2003 13:52:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16840 for <nsis@ietf.org>; Sun, 17 Aug 2003 13:51:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oRh9-0001uo-00 for nsis@ietf.org; Sun, 17 Aug 2003 13:51:59 -0400
Received: from web41215.mail.yahoo.com ([66.218.93.48]) by ietf-mx with smtp (Exim 4.12) id 19oRh9-0001ue-00 for nsis@ietf.org; Sun, 17 Aug 2003 13:51:59 -0400
Message-ID: <20030817175128.33405.qmail@web41215.mail.yahoo.com>
Received: from [67.161.8.79] by web41215.mail.yahoo.com via HTTP; Sun, 17 Aug 2003 10:51:28 PDT
Date: Sun, 17 Aug 2003 10:51:28 -0700
From: Vishal Zinjuvadia <vzinjuvadia@yahoo.com>
To: nsis@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [NSIS] Questions about draft-ietf-nsis-req-09.txt
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>

I had a few questions regarding the nsis req. draft
and would appreciate any help. 

In the following paragraph from the draft:
    
  "2. Something that assists in managing state further
along the signaling path, the NSIS Forwarder.  
    
   The NSIS Forwarder does not interact with higher
layers, but interacts with the NSIS Initiator, NSIS
Responder, and possibly one or more NSIS Forwarders on
the signaling path, edge-to-edge or end-to-end."
   
  I do not completely understand the necessity of
direct interactions between NSIS Forwarder with NSIS
Initiator and NSIS Responder. For example, in the
following diagram:
  
  A-B-C-D-E-F
    |_____|
       |
     Domain  
     
 Assuming that A and F are NSIS Initiators and
Responders respectively and that B-C-D-E belong to the
same domain and are NSIS Forwarders for a particular
session. Why would C or D need to communicate with
either of A or F. I may be missing something important
here and would really appreciate if someone made it
clear for me.

In the following paragraph from the draft:
    
  "6. NSIS assumes layer 3 routing and the
determination of next data node selection is not done
by NSIS."
   
Would this requirement have to change in any way if we
decide to allow the NSIS Initiator some (partial or
complete) control over the path through which the data
for a particular session must flow?

From the draft:

"  5.1.2 NSIS MUST be designed modularly  
    
   A modular design allows for more lightweight
implementations, if fewer features are needed.
Mutually exclusive solutions are supported. Examples
for modularity: 
      
   - Work over any kind of network (narrowband versus
broadband, error-prone versus reliable, ...). This
implies low bandwidth signaling, and elimination of
redundant information MUST be supported if necessary. 

    
   - State setup for uni- and bi-directional flows is
possible 
       
   - Extensible in the future with different add-ons
for certain environments or scenarios  
    
   - Protocol layering, where appropriate. This means
NSIS MUST provide a base protocol, which can be
adapted to different environments. "

I was particularly impressed with the above
requirement. The requirement for Security is known to
be different in different segments of the network and
IMO is a good candidate as an optional composable
module. If soft-state approach is chosen, refresh
reduction may also be a good candidate since it
depends on the number of sessions for which the NSIS
entity has to preserve state. Moreover any NSIS entity
should be able to dynamically compose its stack of
modules to serve the NSIS protocol. This becomes
apparent in wireless networks where the requirements
for any NSIS entity change dramatically depending on
its position (in the access or core) in the network.
This does not affect the draft's suggestions about
handling handovers since NSIS sessions may have to be
resignalled in such a case anyway.

One question I had was: Would the role of the NSIS
entity (NI,NF,NR) have any affect on what modules
compose its set of features for the NSIS protocol. How
would we handle situation where a single NSIS entity
has multiple roles for multiple sessions that it is a
part of? Running multiple processes might be an
overkill and defeat the whole purpose.

From the draft:

"  5.4.5 Grouping of signaling for several micro-flows
MAY be provided 
    
   NSIS MAY group signaling information for several
micro-flow into one signaling message. The goal of
this is the optimization in terms of setup delay,
which can happen in parallel. This helps applications 
  requesting several flows at once. Also potential
refreshes (in case of a soft state solution) might
profit from grouping.  
       
   However, the network needs not know that a
relationship between the grouped flows exists. There
MUST NOT be any transactional semantic associated with
the grouping. It is only meant for optimization
purposes."

Let us assume that three NSIS sessions exist 1) A (NI)
and G(NR),
2) B(NI) and H (NR) and 3) C(NI) and I(NR)
   
A---+               +---G
    |               |  
B---+---D---E---F---+---H
    |               | 
C---+               +---I

Does the grouping of signaling for micro-flows apply
to this situation. In other words, would D attempt to
group signaling information for the three NSIS
signaling messages it receives from A, B and C?
    
Lastly, there was no mention of prioritization of NSIS
resource requests - for e.g. a NSIS request with
higher priority may terminate an existing NSIS
reservation and make the resources available. Has it
been left out on purpose or covered implicitly
somewhere in the draft?

Thanks for patiently going through the email. I would
appreciate any comments and/or answers to these
questions.

Regards,
Vishal

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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