headers
Marcus Brunner | 5 Aug 2003 16:32
Picon

RE: mobility-related requirements from nsis-req-08


> 1. The identifier that should not change during mobilily (if there is
> one) is called the Session Identifier, while its detailed structure is
> still open.
> [reh] this is my view. designing it is an NTLP design matter (i.e.
> the framework at least will not comment further on it). i think this
> is generally agreed so far as it goes.
>

Yes, I think it is even a design requirement in the req draft.

> 2. The flow identifier is the low level identifier that is used to
> acutally route the packet at the NTLP level, its structure could contain
> IP 5-tuple, IPv6 flow label, or related IP fields.
> [reh] this is also my view. the precise definition is 'it has to contain
> whatever fields that are used by routers to route packets'. discussion
> post-Vienna on the mailing list implies to me that this is also generally
> agreed.

I think it is agreed not seen any objection.

 Marcus
Permalink | Reply | 0 comments |
headers
john.loughney | 7 Aug 2003 04:30
Picon

RE: Reliable Transport for NTLP

Hi Rüdiger,

> As I mentioned in another mail, I think reliablbe transport isn't required 
> if there's a "low" amount of signaling to be processed. If NSIS will be 
> designed to prevent a "high" signaling load in backbones, I guess I 
> won't have a problem. Besides RSVP TE (and DiffServ aware TE) there's also 
> RFC 3175 ( aggregated RSVP). Both aim on rather stable state in the 
> backbone by flow aggregation. 

So, what I suspect what you are saying, that in the presences of multiple
different NLSPs between two NSIS peers, aggregation is needed.  Flows
which are aggregated should be congestion-friendly, etc.  I think that
this is the direction which Henning aiming for with NTLP.

John
Permalink | Reply | 0 comments |
headers
john.loughney | 7 Aug 2003 04:30
Picon

RE: Reliable Transport for NTLP

Hi Robert,

> However, even if we agree that a signalling application
> needing reliability needs it between (say) adjacent NSLP
> peers rather than simply end-to-end, there is still the 
> question of which layer it should be provided at (NTLP
> or within each application).

The question could be put another another way, can a NSLP 
'reliably' rely on a multi-hop NTLP providing reliability?
Will an NSLP need to augment NTLP-layer reliability with
reliability at the NSLP layer (such as explicit acks, 
retransmission timers, etc)?

John
Permalink | Reply | 501 comments |
headers
Seong Ho Jeong | 7 Aug 2003 05:19
Picon
Favicon

Crossover node discovery issue

Hi Robert,

In Section 5.2.2 (Localized Path Repair) of the framework document, 
I think it would be good to give a general description of how to discover the 
crossover node in a little more detail. For example, as discussed before, a session ID, 
a flow ID, and/or a mobility object can be used for the crossover node discovery. 
In this case, we may also need to check whether or not the use of those fields is 
sufficient because some sort of authorization and determination of session ownership may be 
necessary...How about adding a general description of the crossover node discovery 
and related security issues to the framework document?

Regards, 

Seong Jeong
Permalink | Reply | 0 comments |
headers
Hancock, Robert | 7 Aug 2003 10:57
Picon

RE: Reliable Transport for NTLP

john,

even between two adjacent NSLP peers, there are really two questions
(which are nearly independent):

1. what's the best layer to provide a guarantee that a message has
got from one to the other.

2. what's the best layer to detect and recover from a message loss
within the network.

i'm still finishing off my reliability analysis draft at the moment.
but my current feeling is that there are really at least two aspects
to reliability
- making sure the message arrives in the face of congestion, corruption
and so on, and retransmitting rapidly if not (the NTLP is best place to
do this but intermediate NTLP-only nodes shouldn't take part in
the process)
- making sure that a message has been processed and acted on correctly,
and this has to be an NSLP responsibility.

and, overall reliability at the 'e2e' level, e.g. between source and
destination, has to be an NSLP responsibility also (e.g. our QoS-NSLP 
had a confirmation request object for this purpose).

r.

> -----Original Message-----
> From: john.loughney <at> nokia.com [mailto:john.loughney <at> nokia.com]
> Sent: Thursday, August 07, 2003 03:30
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henning Schulzrinne | 8 Aug 2003 02:23

Re: Reliable Transport for NTLP

I see these as complementary. End-to-end reliability is good for dealing 
with node failures, for example, which are relatively rare and have 
longer time constants for discovery. In many cases, softstate 
'reliability' (on the order of 30s) should do the trick there.

john.loughney <at> nokia.com wrote:

> Hi Robert,
> 
> 
>>However, even if we agree that a signalling application
>>needing reliability needs it between (say) adjacent NSLP
>>peers rather than simply end-to-end, there is still the 
>>question of which layer it should be provided at (NTLP
>>or within each application).
> 
> 
> The question could be put another another way, can a NSLP 
> 'reliably' rely on a multi-hop NTLP providing reliability?
> Will an NSLP need to augment NTLP-layer reliability with
> reliability at the NSLP layer (such as explicit acks, 
> retransmission timers, etc)?
> 
> John
Permalink | Reply | 501 comments |
headers
Xiaoming Fu | 11 Aug 2003 15:43
Picon

Re: mobility-related requirements from nsis-req-08

Robert,

Sorry for the delay in answering your mail - I just came back from a few 
days of vocation. Some comments inline:

Hancock, Robert wrote:
> hi xiaoming,
> 
(snip)
> [reh] the fundamental question is: how are the data packets themselves
> being routed? whatever is making them follow the route they follow
> should be invoked to make the signalling packets follow the same route.
> (*how* to make that invocation is another issue; one approach is to
> make the signalling packets look like data packets, another is to 
> make the nodes which do some forwarding which is not-purely-IP-DA
> NSIS-aware and have them route signalling packets at the NTLP level
> on the flow-id directly. see numerous other emails on that subject.)
> 
> [if the data packets are being routed on something other than 3/5 tuple
> and possibly routing header, I suspect we are in deep trouble.]

I totally agree with you that signaling packets should follow exactly 
the same route as data packets (I believe this is part of the NSIS 
requirements regarding mobility and any other things). Now let's go to 
the problem of "how the data packets are routed in mobile IP?" and look 
at CN-->MN in basic Mobile IPv6 protocol first:

- For Mobile IP without route optimization: the data packets will stay 
as normal IP packets (src: CN, dst: HoAddress) before arriving at the 
HA. The HA uses IP-in-IP encapsulation to assemble these packets towards
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcus Brunner | 12 Aug 2003 11:33
Picon

New version of Req submitted

John, Allison,

I have a new version of the requirements submitted 
(draft-ietf-nsis-req-09.txt). The comments from Harald and Steve have been 
addressed (see below for the difference between the 08 and 09 of the draft.

Marcus

Section 5 (Harald's comment #1)

OLD

5 Requirements

This section defines more detailed requirements for a signaling solution, 
respecting the framework, scoping assumptions, and terminology considered 
earlier. The requirements are in subsections, grouped roughly according to 
general technical aspects: architecture and design goals, topology issues, 
parameters, performance, security, information, and flexibility.

Two general (and potentially contradictory) goals for the solution are that 
it should be applicable in a very wide range of scenarios, and at the same 
time lightweight in implementation complexity and resource consumption 
requirements in NSIS Entities. One approach to this is that the solution 
could deal with certain requirements via modular components or 
capabilities, which are optional to implement or use in individual nodes.

In order to prioritize the various requirements we informally define 
different 'parts of the network'. In the different parts of the network a 
particular requirement might have a different priority.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Internet-Drafts | 12 Aug 2003 16:17
Picon
Favicon

I-D ACTION:draft-ietf-nsis-req-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Steps in Signaling Working Group of the IETF.

	Title		: Requirements for Signaling Protocols
	Author(s)	: M. Brunner
	Filename	: draft-ietf-nsis-req-09.txt
	Pages		: 36
	Date		: 2003-8-12
	
This document defines requirements for signaling across different 
network environments, such as across administrative and/or 
technology domains. Signaling is mainly considered for Quality of 
Service such as The Resource Reservation Protocol, however in recent 
years several other applications of signaling have been defined such 
as signaling for label distribution in Multiprotocol Label Switching 
or signaling to middleboxes. To achieve wide applicability of the 
requirements, the starting point is a diverse set of scenarios/use 
cases concerning various types of networks and application 
interactions. This document presents the assumptions before listing 
the requirements.  The requirements are grouped according to areas 
such as architecture and design goals, signaling flows, layering, 
performance, flexibility, security, and mobility.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-09.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hancock, Robert | 13 Aug 2003 00:25
Picon

framework: proposal on reliability

dear all,

we've had multiple inconclusive discussions on reliability
requirements for the NTLP in the recent and distant past.

i've tried to summarise them and provide some additional
factoids for consideration in an i-d. while the i-d editor
processes it, you can find it at
http://sigcomp.srmr.co.uk/~reh/draft-hancock-nsis-reliability-00.txt

my conclusions from all this are:

                             ...it is appropriate for the NTLP 
   to provide a reliable message delivery service, which would be 
   optional for signaling applications to use. The role of such a 
   service would be limited to ensuring rapid delivery of messages to 
   the nodes where they are to be processed in signaling applications, 
   and not to provide any application-layer state synchronization 
   service or hard-state support. Such a reliability service should if 
   possible be implemented in a way which can be transparent to 
   intermediate NSIS nodes which don't take part in the signaling 
   application; it will probably require congestion control in the NTLP 
   as a consequence. 

If you disagree with this conclusion, take a look at the draft and 
tell me why. Apart from congestion control (a closely related subject),
I regard this as the single major outstanding technical issue with the
framework, and would like to see how we can finish off that discussion
during August and early September (if that's possible).
(Continue reading)

Permalink | Reply | 72 comments |

Gmane