Subject: RE: [NSIS] input (over RMD) for NSIS Analysis draft

From: Attila Báder (ET/ETH)<[email-masked]>
Date: Tue, 22 Jul 2003 18:48:12 +0200

Hi Nary,

Thank you for your comments, please see my answers inline.

Best regards,  Attila

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Thanh
> Tra LUU
> Sent: Saturday, July 19, 2003 9:37 AM
> To: karagiannis
> Cc: [email-masked]
> Subject: Re: [NSIS] input (over RMD) for NSIS Analysis draft
> 
> 
> Hi,
> 
> I've read the draft of proposal for RSVPv2 NSLP. I have some
> questions.
> 
> - For bi-directional reservation, you call NI (sender) and
> NR(receiver), it makes me confused because both of end hosts can be
> receiver and sender. Supposing the bi-directional reservation between
> A (and RSVPv2 aware) and B (another RSVPv2 aware end host) is
> initiated by  A (NI) . The two  reservation can be established on two
> different paths. The announcement of reservation success (A -> B) is
> carried by packet Path(NslpPathInit) from B to A. Because of asymmetry
> of routing, it is possible that the intermediate NTLP stateful nodes
> between A and B don't receive this message to know the success of
> reservation. They will only know it after receiving the refresh
> message from sender. In case unidirectional reservation, the
> intermediate nodes know it by receiving the NslpResvInit. Why is there
> this difference ? Is it useful ?

I agree with you that NI and NR notations can be confusing in case of bidirectional resrevation. Especially if NSLP supports different types of bi-directional reservation methods. We should think of a better terminology for the next nslp design draft.

In our concept general rules are: sender and ingress edge nodes should receive acknowledgement, other statefull NF nodes and egress edge nodes may get acknowledgement, NTLP stateless nodes cannot receive acknowledgement. In case of unidirectional reservation, NslpResvInit is sent back in RESV message, which is routed by NTLP, therefore NFs can get acknowledgement easily. In case of bidirectional reservation acknowledgement to NI is sent in PATH(NslpPathInit) in the simplest case. RESV(NslpResvInit) may be sent in both direction if NFs need acknowledgement. (This example is not shown in the figures.)

> - I don't understand how the NTLP stateless node can support the
> routing change. No state is established when NTLP stateless receives a
> Path(NslpPathInit) message. When NTLP stateless receives a
> Path(NslpPahInit), it adds the new required reservation units of  a
> traffic class. When it receives a PathTear(NslpPathTear), it will
> subtract the required resource. As previous mail, you said
> "simultaneously maintained RMD reservation states in the interior
> nodes is equal to the number of the supported traffic classes", that
> means if there is a routing change, a deletion of a flux can delete a
> required resource on a intermediate NTLP stateless node which was not
> previously on the data path.
> 

In stateless nodes we have to rely on soft states. If routing changes in the domain, two things can happen. If it does not cause packet drop or delay, edge nodes do not notice route change, resources in the new route are added and resources along the old routes are removed automatically after time-out. If routing causes packet drop or delay, data packets are marked, which notify edge node. Edge node may block this flow and resource is removed after time out. You are right PathTear(NslpPathTear) should not be sent in this case, I think the figure in the draft is wrong.  

> - I don't understand refresh mechanism for the interior NTLP stateless
> node either. How does a interior NTLP stateless nodes know a refresh
> message belongs to a specific flux of a traffic class ? If there is
> not the refresh for a flux in the NTLP stateless nodes, what does the
> refresh mean here ?
> 

The interior node does not know to which flow a resource unit belongs to. Refresh means, adding x number of resource units to a traffic class state. y resource unit, reserved in the previous refresh period is released. To be more exact the refresh period is divided to n number of time slots, and refresh units per slot per traffic class is counted and released after time out.

> - For the severe congestion handling, interruption of a flux which is
> reserved doesn't seems interesting to me. If I want to reserve
> resource for a VoIP communication, it's better if network refuses the
> connection before I can begin the conversation rather than disrupt my
> communication.
> 
Yes agree but severe congestion refers to an unexpected situation during call, like route change due to link or node failure. In new route all flows may can not be supported, some have to be terminated.

> Nary Tra
> ENST, Paris
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis