Subject: [NSIS] motivation of using RSVPv1 as NTLP

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 21 Feb 2003 11:06:12 +0100

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

---

From: Ping Pan <[email-masked]>
Date: Fri, 21 Feb 2003 16:56:34 -0800

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