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

From: "karagiannis" <[email-masked]>
Date: Thu, 17 Jul 2003 09:23:58 +0000

Hi Jukka

Please receive a proposed text related to the analysis of the RMD 
(Resource Management in DIffserv) specification that can be used as 
an input (section) for the NSIS Analyisis draft.
If there are comments please let me know!
Please note that during the following three weeks I will be out of
office.
You could forward the comments to Lars Westberg or Attila Bader!

Best Regards,
Georgios

-----------------------------------------------------
x.x Resource Management in Diffserv (RMD)

Resource Management in Diffserv (RMD) [WeCs02] represents a QoS framework

that extends the Diffserv principles with new ones necessary to provide 
dynamic resource management and admission control in Diffserv domains.  
The development of RMD was initially based on two main design goals. The 
first one was that RMD should be stateless on some nodes (e.g. interior 
routers), i.e., no per-flow state is used, unlike RSVP [RFC2205], which 
installs one state for each flow on all the nodes in the communication
path. 
The second goal was that RMD even though stateless should associate each 
reservation to each flow and therefore should provide certain QoS
guarantees
for each flow. These two goals are met by separating a complex reservation

mechanism used in some nodes from a much simpler reservation mechanism 
needed in other nodes. In particular, it is assumed that some nodes will 
support &#8220;per-flow states&#8221;, i.e., are stateful. In RMD these
nodes are 
denoted as &#8220;edge nodes&#8221;. However, any nodes that maintain
reservation states
could fulfill this requirement. The second assumption is that the nodes 
between these stateful nodes can have a simpler execution by using only
one 
aggregated reservation state per traffic class. In RMD these nodes are 
denoted as interior nodes. 
The separation of the complex per domain reservation mechanism from the 
simple reservation mechanism needed for a node is accomplished by using
two types of protocols the Per Domain Reservation (PDR) protocol and the 
Per Hop Reservation (PHR) protocol. The PDR protocol is used for resource
management in the whole Diffserv domain and is used only on the edge
nodes, 
while the PHR protocol is used for managing resources for each node, on 
per hop basis and per traffic class. The PDR protocol can either be a
newly 
defined protocol or an existing one such as RSVP [RFC2205], while the PHR

protocol is a newly defined protocol. The PDR reservation states at the 
edge nodes are identified by a flow Identifier (ID). This flow ID depends

on the used existing reservation protocol. For example, a flow ID 
specification can be a combination of source IP address, destination IP 
address and the Diffserv Code Point (DSCP) field. The PHR reservation 
states are per traffic class aggregated states that are identified 
by a DSCP. The edges will generate reservation requests for each flow, 
similar to RSVP, but in order to achieve simplicity in interior nodes, a 
measurement-based approach on the number of the requested resources per 
traffic class, i.e., per Per Hop Behavior, is applied. In practice, this 
means that the aggregated reservation state per traffic class in the 
interior nodes is updated by a measurement-based algorithm that uses the 
requested and available resources as input. Moreover, RMD applies
admission 
control on resource parameter values included in the reservation requests,

i.e. signaling messages and available resources per traffic class.

RMD is a sender oriented reservation protocol that can only be used for
unicast reservations and can be applied with both IP versions, IPv4 and 
IPv6. Multicast reservations are not supported.  
Due to the fact that RMD is used as a sender oriented reservation
protocol, 
backward reservation states in the interior nodes are not supported. The 
RMD protocol can support both uni-directional and bi-directional 
reservations.

The authors of the RMD proposal show in [WeCs02] that the number of 
simultaneously maintained RMD reservation states in the interior nodes are

independent of the number of simultaneously maintained flows. The number
of 
simultaneously maintained RMD reservation states in the interior nodes is

equal to the number of the supported traffic classes, i.e., supported 
Diffserv Per Hop Behaviors.

Compared to RSVP, the RMD protocol provides limited functionality, 
i.e., no security and policy based interworking are provided. 
Due to the limited functionality of the RMD protocol, its 
messages are short and consume a relatively low amount of bandwidth.

The authors of the RMD proposal show in [WeCs02] that the message 
processing of the RMD protocol implementation is considerable lower 
than the message processing of the ISI RSVP protocol implementation. This

is mainly due to the limited functionality supported by the RMD protocol.

Regarding the deployability issues, RMD is an edge to edge protocol. 
Therefore, it has to be integrated/interoperated with an end to end 
reservation protocol.

References:
--------------
[RFC2205] given in version 03 of the Analysis draft

[WeCs02] Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., 
Partain, D., Pop, O., Rexhepi, V., Szabo, R., Takacs, A., "Resource 
Management in Diffserv: A Functionality and Performance Behavior
Overview", 
Seventh International Workshop on Protocols for 
High-Speed Networks - PfHSN 2002, 2002.

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

---

From: Roland Bless <[email-masked]>
Date: Thu, 17 Jul 2003 19:48:55 +0200

Hi Georgios,

> If there are comments please let me know!

I think it should be emphasized that RMD is an _intra-domain_ 
resource management scheme. Further comments below.

> Diffserv Per Hop Behaviors.

What about the number of messages that has to be processed 
per interior node?

> Regarding the deployability issues, RMD is an edge to edge protocol. 
                                              ^^^
                                               intra-domain

Wouldn't it be good to mention special requirements for the signaling
protocol to make your scheme work?

Regards,
 Roland