[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
- [NSIS] Questions about draft-ietf-nsis-req-09.txt Vishal Zinjuvadia
- RE: [NSIS] Questions about draft-ietf-nsis-req-09… Hancock, Robert
- RE: [NSIS] Questions about draft-ietf-nsis-req-09… Marcus Brunner
- RE: [NSIS] Questions about draft-ietf-nsis-req-09… Vishal Zinjuvadia