RE: [NSIS] Re: Modularity and grouping QoS requirements

Hi Cedric,

|one reason for using the model in draft-nsis rather than the one in
|draft-partain is that it allows to define mobility requirements.

I do not agree. In the draft-partain QoS requirements are derived from 
particular scenarios, one of them being the Mobile IP scenario and the
mobility requirements are part of the draft.
In the Mobile IP scenario this is already shown, when a handoff 
occurs the new reservation is needed from the NAR to the "Joint point 
of reservation" router that is located into the QoS aware segment that 
maintains an end to end reservation but due to handover it 
may change/modify this reservation.  

[NSIS] WG draft on the other hand on the mobility requirements refers
draft-ietf-mobileip-qos-requirements-01.txt.
If you compare the draft-partain and draft-ietf-mobileip-qos-requirements-02.txt.
you'll see that that these mobility requirements are in both drafts.

|For instance, think of a handoff, where the previous access 
|router (PAR)
|transfers QoS context to the new access router (NAR).
|There is no NAR-PAR interface in draft-partain; however, it is easy
|to see that the NAR is a QC (making the CAC decision at least) for
|the new path, and PAR a QI.
Note that in draft-partain the Access Routers are denoted as Border Node, 
so one of the QoS context transfer requirements that will apply to an 
interface similar to your the NAR-PAR is given in 
Section 5.2.2, draft-partain.
However, this is not explained in detail how it would be done. Probably
there may be more issues related to the interworking with QoS context
transfer protocols defined in SEAMOBY.
Do you already see any other requirements on such interface?

|Another drawback of the 'interface' framework is that QoS signaling is
|not necessary limited to interfaces. For instance, to update some 
|reservation
|after a handoff, you'd need to signal to the crossover router(s), 
|wherever it
|is. Most likely this crossover router does not correspond to 
|any interface.
|Note that draft-nsis either does not provide such framework, 
|but it could
|easily (should) be added with a QoS Termination point 
|abstraction. I think
|it is a dead end to assume the starting point and the end point of the 
|QoS signaling to
|be some pre-defined interface. Draft-nsis goes a half step in the right
|direction by allowing the starting point to be anywhere and 
|abstracting 
|it into
|the QI, which is a better starting point.
The purpose of grouping the requirements according to different 
interfaces where they apply to is not to limit the starting and ending
point of the protocol. The purpose is to see which requirements apply
to different parts of the network in the end-to-end path. We all agree
that what is needed in the access is not the same as what is needed 
in the core, which means that we need to identify these requirements for
a protocol that we would like to use end-to-end. The only way to achieve 
this is by supporting modularity in the protocol.
Further draft-partain does not restrict the starting point of the
protocol either.
The major problem in the [NSIS] WG draft is that the requirements are
deined for the abstract entities QI/QC and if there is no idea on where
in the network this requirements apply it is going to be difficult to 
design an NSIS protocol fulfilling these requirements.

Regards,
Vlora

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