Subject: [NSIS] Multicast v.s. unicast in RSVP

From: Xiaoming Fu <[email-masked]>
Date: Tue, 25 Jun 2002 13:49:07 +0200

Hi all,

Section 3.2.5 "Multicast versus Unicast" of [draft-hancock-nsis-fw-00.txt]
states:
   Multicast support, compared to unicast support, would introduce a 
   level of complexity into the NSIS protocol mainly related to: 
   * complex state maintenance to support dynamic membership changes in 
   the multicast groups, such as reservation state merging and 
   maintenance. 
   * a state per flow has to be maintained that is used during backward 
   routing. 
    
RSVP, as a typical example, supports dynamic multicast member
and large number of heterounous (QoS request of the) receivers. 
We think multicast brings more mandatory features to RSVPv1 than 
that described above:

- Optimized as receiver-initiated way to support multicast receivers
especially, heterounous (QoS request of the) receivers

- Two-pass (Path/Resv) signaling message exchange (which results in
complex state management)

- Specification on "reservation styles" to tell network nodes
which set of receivers and how simular these receivers' QoS request 
are (having to be used anywhere)

- Complicated error handling (e.g., killer problems)

These are analyzed in [draft-fu-rsvp-multicast-analysis-00.txt]. 

Due to the fact that vast majority of application being unicast,
We think it could be interesting to remove multicast in RSVP. 
Although sender-initiated is recommended for a such simplication,
it is possible to support both sender-initiated and receiver-initiated 
way, via high-level interaction of protocol components. 
In principle, end-to-end bi-directional way could be supported
as well, however, hop-by-hop bi-directional support 
depends on the network topology and could be locally 
optimized if an AS (even an RSVPhop-RSVPhop pair) supports 
symmetric routing of data packets.

A potential implication due to the sender-initiated one-way
signaling message is some simpler abstraction like "QoS profile"
could be used instead of Sender_TSpec/AdSpec and FlowSpec, 
even it would probably not developed within NSIS.

Still, how to support multicast capability by a unicast-dedicated 
RSVP-variant would be an open issue. Nevertheless, we notice that 
there are some examples considering multicast as a function built 
on top of unicast routing rather than as an integral part of it.

Thanks,
Xiaoming

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