Subject: RE: [NSIS] motivation of using RSVPv1 as NTLP

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 24 Feb 2003 10:48:19 +0100

Hi Ping

Well what is says is, 
Use as NTLP mandatory transport 
features the mandatory RSVPv1 transport features!

Your motivation would be:
Why should you use simple solutions, when 
you can invent complex ones :-)

Best Regards,
Georgios

-----Original Message-----
From: Ping Pan [mailto:[email-masked]]
Sent: zaterdag 22 februari 2003 1:57
To: Georgios Karagiannis (ELN)
Cc: [email-masked]
Subject: Re: [NSIS] motivation of using RSVPv1 as NTLP

Georgios,

Your argument below simply says since RSVPv1 has been designed, let's 
continue to use it (though it has some flaws). Unfortunately, in this 
logic, we should simply use GRE as NTLP. At least GRE has more 
deployment than RSVP. :-)

- Ping

Georgios Karagiannis (ELN) wrote:
> Hi all 
> 
> Below I try to give a motivation of why is good 
> to use RSVPv1 (RFC2205) as NTLP!
> 
> 
>    A great deal of effort was put into the specification and design
>    of the RSVPv1 (RFC2205) protocol.  RSVPv1 is well-designed for 
>    the applications for which it was intended and worked hard to provide 
>    a modular protocol within the constraints of its intended use. 
>    The NSIS WG uses the two-level architecture for Internet Signaling
>    proposed in (in Bob's two-level architecture draft):
> 
>       (1) a common lower level that performs transport-layer functions.
>           This common lower level is denoted in (NSIS framework draft)
>           as NSIS Transport Layer Protocol (NTLP) that is a placeholder
>           name for the NSIS protocol component that will support lower
>           layer (signaling application independent) functions.
>       (2) a set of upper-level signaling functions that are specific
>           to particular signaling applications. These upper-level
>           signaling tasks and functions are accomplished by a set of
>           signaling layer protocols denoted in (NSIS framework draft)
>           as NSIS Signaling Layer Protocol (NSLP).
> 
>    The main transport-layer features supported by RSVPv1 (RFC2205), such 
>    as support of unicast path-coupled signaling and soft state support 
>    have been proven in practice of being lightweight and robust. However, 
>    the multicast support introduces a level of complexity into the RSVPv1 
>    protocol that is not needed in support of unicast applications.  For 
>    example, RSVPv1's state maintenance is complex as it needs to support 
>    dynamic membership changes in the multicast groups, such as reservation 
>    state merging and maintenance.
> 
>    Our working assumption is that RSVPv1 should be optimized for unicast
>    rather than multicast and that relaxing this design constraint will
>    in turn greatly simplify the protocol.
> 
>    Using RSVPv1 as NTLP will eliminate the need of reinventing solutions
>    for transport-layer features. Furthermore, this will shorten the time 
>    needed to standardize NTLP by reusing the current RSVP design 
>    experience and RSVP protocol specification. Moreover, after minor 
>    modifications, existing RSVPv1 (RFC2205) implementations can be reused 
>    and used as NTLP, decreasing the deployment costs.
> 
>    Additional transport-layer features can be introduced in a modular way, 
>    either by adding them one by one as optional features into the NTLP 
>    specifications and implementations or using an existing protocol below 
>    NTLP that could provide these additional features.
> 
> Best regards,
> Georgios
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

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