[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [NSIS] QoS NSLP -- 4.7. Reduced State or Stateless Interior Nodes
Hi Hannes
Thank you very much for your comments!
Sorry for the delay!
Please see in line!
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig at gmx.net]
> Sent: donderdag 9 augustus 2007 11:06
> To: nsis at ietf.org
> Subject: [NSIS] QoS NSLP -- 4.7. Reduced State or Stateless
> Interior Nodes
>
> I do not quite understand how the stateless interior nodes work.
>
> I understand that you do not store GIST state for reverse
> routing. I also understand that there is a desire not to
> install per-flow reservations.
>
> But if there is no state stored at all, as mentioned in
> Section 4.7 of the QoS NSLP, then what's the point of signaling?
Georgios: Signaling is usefull even when a node does not support state,
e.g.,
measurement based admission control schemes. Furthermore, signaling is also
usefull for schemes
That are using reduced states.
>
> I also believe that Section 4.7 is missing an important point:
>
> If a reservation request fails then the RESERVE message is
> forwarded until it hits the egress node. In standard QoS NSLP
> operation a RESPONSE message would be returned immediately
> when an error is detected.
Georgios: You are right this procedure is missing, but is inluded in other
sections of this draft,
The QSPEC template draft and in QOS models drafts, such as RMD-QOSM.
We could also mention it in this section.
>
> Here is a figure:
>
> Please view in a fixed-width font such as Courier.
>
> QNE QNE QNE QNE
> ingress interior interior egress
> GIST stateful GIST stateless GIST stateless GIST stateful
> | A B |
> RESERVE | | | |
> -------->| RESERVE | | |
> +--------------------------------------------->|
> | RESERVE' | | |
> +-------------->| | |
> | | RESERVE' | |
> | +-------------->| |
> | | | RESERVE' |
> | | +------------->|
> | | | RESPONSE' |
> |<---------------------------------------------+
> | | | | RESERVE
> | | | +-------->
> | | | | RESPONSE
> | | | |<--------
> | | | RESPONSE |
> |<---------------------------------------------+
> RESPONSE| | | |
> <--------| | | |
>
> Assume that the RESERVE' message fails at node A. Then, a
> RESPONSE cannot be sent back to the ingress but instead the
> message continues its way towards the egress node.
Georgios: right!
>
> It is, however, necessary to mark the message in a way that
> subsequent nodes (in this case node B) does not attempt to
> make a reservation but just forwards the message as is.
Georgios: right!
>
> When the egress node receives the message it then constructs
> a RESPONSE'
> message indicating the failure of the reservation attempt.
Georgios: right!
>
> This procedure requires additional protocol mechanisms to support
> a) marking a message as failed
> b) allow the state machine to forward the message in this
> particular mode even though the reservation failed.
Georgios: The above mechanisms can be accomplished, since they
are already described in Section 5 and in the QSPEC template draft!
However, it will make this section more clear if we will add
the above steps also in this section!
Best regards,
Georgios
>
> I don't see any of these things in the document. A bug or intention?
>
> Ciao
> Hannes
>
>
>
> _______________________________________________
> nsis mailing list
> nsis at ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis