rfc2382.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   messages that would change the QoS of that VC that arrive before time
   t+T would be queued. If several messages changing the QoS of a VC
   arrive during the interval, redundant messages can be discarded. At
   time t+T, the remaining change(s) of QoS, if any, can be executed.
   This timer approach would apply more generally to any network
   structure, and might be worthwhile to incorporate into RSVP.







Crawley, et. al.             Informational                     [Page 20]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   The sequence of events for a single VC would be

   - Wait if timer is active
   - Establish VC with new QoS
   - Remap data traffic to new VC
   - Tear down old VC
   - Activate timer

   There is an interesting interaction between heterogeneous
   reservations and dynamic QoS. In the case where a RESV message is
   received from a new next-hop and the requested resources are larger
   than any existing reservation, both dynamic QoS and heterogeneity
   need to be addressed. A key issue is whether to first add the new
   next-hop or to change to the new QoS. This is a fairly straight
   forward special case. Since the older, smaller reservation does not
   support the new next-hop, the dynamic QoS process should be initiated
   first. Since the new QoS is only needed by the new next-hop, it
   should be the first end-point of the new VC.  This way signalling is
   minimized when the setup to the new next-hop fails.

4.2.8 Short-Cuts

   Short-cuts [4] allow ATM attached routers and hosts to directly
   establish point-to-point VCs across LIS boundaries, i.e., the VC
   end-points are on different IP subnets.  The ability for short-cuts
   and RSVP to interoperate has been raised as a general question.  An
   area of concern is the ability to handle asymmetric short-cuts.
   Specifically how RSVP can handle the case where a downstream short-
   cut may not have a matching upstream short-cut.  In this case, PATH
   and RESV messages following different paths.

   Examination of RSVP shows that the protocol already includes
   mechanisms that will support short-cuts.  The mechanism is the same
   one used to support RESV messages arriving at the wrong router and
   the wrong interface.  The key aspect of this mechanism is RSVP only
   processing messages that arrive at the proper interface and RSVP
   forwarding of messages that arrive on the wrong interface.  The
   proper interface is indicated in the NHOP object of the message.  So,
   existing RSVP mechanisms will support asymmetric short-cuts. The
   short-cut model of VC establishment still poses several issues when
   running with RSVP. The major issues are dealing with established
   best-effort short-cuts, when to establish short-cuts, and QoS only
   short-cuts. These issues will need to be addressed by RSVP
   implementations.

   The key issue to be addressed by any RSVP over ATM solution is when
   to establish a short-cut for a QoS data flow. The default behavior is
   to simply follow best-effort traffic. When a short-cut has been



Crawley, et. al.             Informational                     [Page 21]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   established for best-effort traffic to a destination or next-hop,
   that same end-point should be used when setting up RSVP triggered VCs
   for QoS traffic to the same destination or next-hop. This will happen
   naturally when PATH messages are forwarded over the best-effort
   short-cut.  Note that in this approach when best-effort short-cuts
   are never established, RSVP triggered QoS short-cuts will also never
   be established.  More study is expected in this area.

4.2.9 VC Teardown

   RSVP can identify from either explicit messages or timeouts when a
   data VC is no longer needed.  Therefore, data VCs set up to support
   RSVP controlled flows should only be released at the direction of
   RSVP. VCs must not be timed out due to inactivity by either the VC
   initiator or the VC receiver.   This conflicts with VCs timing out as
   described in RFC 1755 [11], section 3.4 on VC Teardown.  RFC 1755
   recommends tearing down a VC that is inactive for a certain length of
   time. Twenty minutes is recommended. This timeout is typically
   implemented at both the VC initiator and the VC receiver.   Although,
   section 3.1 of the update to RFC 1755 [11] states that inactivity
   timers must not be used at the VC receiver.

   When this timeout occurs for an RSVP initiated VC, a valid VC with
   QoS will be torn down unexpectedly.  While this behavior is
   acceptable for best-effort traffic, it is important that RSVP
   controlled VCs not be torn down.  If there is no choice about the VC
   being torn down, the RSVP daemon must be notified, so a reservation
   failure message can be sent.

   For VCs initiated at the request of RSVP, the configurable inactivity
   timer mentioned in [11] must be set to "infinite".  Setting the
   inactivity timer value at the VC initiator should not be problematic
   since the proper value can be relayed internally at the originator.
   Setting the inactivity timer at the VC receiver is more difficult,
   and would require some mechanism to signal that an incoming VC was
   RSVP initiated.  To avoid this complexity and to conform to [11]
   implementations must not use an inactivity timer to clear received
   connections.

4.3 RSVP Control Management

   One last important issue is providing a data path for the RSVP
   messages themselves.  There are two main types of messages in RSVP,
   PATH and RESV. PATH messages are sent to unicast or multicast
   addresses, while RESV messages are sent only to unicast addresses.
   Other RSVP messages are handled similar to either PATH or RESV,
   although this might be more complicated for RERR messages.  So ATM
   VCs used for RSVP signalling messages need to provide both unicast



Crawley, et. al.             Informational                     [Page 22]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   and multicast functionality.  There are several different approaches
   for how to assign VCs to use for RSVP signalling messages.

   The main approaches are:

      - use same VC as data
      - single VC per session
      - single point-to-multipoint VC multiplexed among sessions
      - multiple point-to-point VCs multiplexed among sessions

   There are several different issues that affect the choice of how to
   assign VCs for RSVP signalling. One issue is the number of additional
   VCs needed for RSVP signalling. Related to this issue is the degree
   of multiplexing on the RSVP VCs. In general more multiplexing means
   fewer VCs. An additional issue is the latency in dynamically setting
   up new RSVP signalling VCs. A final issue is complexity of
   implementation. The remainder of this section discusses the issues
   and tradeoffs among these different approaches and suggests
   guidelines for when to use which alternative.

4.3.1 Mixed data and control traffic

   In this scheme RSVP signalling messages are sent on the same VCs as
   is the data traffic. The main advantage of this scheme is that no
   additional VCs are needed beyond what is needed for the data traffic.
   An additional advantage is that there is no ATM signalling latency
   for PATH messages (which follow the same routing as the data
   messages).  However there can be a major problem when data traffic on
   a VC is nonconforming. With nonconforming traffic, RSVP signalling
   messages may be dropped. While RSVP is resilient to a moderate level
   of dropped messages, excessive drops would lead to repeated tearing
   down and re-establishing of QoS VCs, a very undesirable behavior for
   ATM. Due to these problems, this may not be a good choice for
   providing RSVP signalling messages, even though the number of VCs
   needed for this scheme is minimized. One variation of this scheme is
   to use the best effort data path for signalling traffic. In this
   scheme, there is no issue with nonconforming traffic, but there is an
   issue with congestion in the ATM network. RSVP provides some
   resiliency to message loss due to congestion, but RSVP control
   messages should be offered a preferred class of service. A related
   variation of this scheme that is hopeful but requires further study
   is to have a packet scheduling algorithm (before entering the ATM
   network) that gives priority to the RSVP signalling traffic. This can
   be difficult to do at the IP layer.







Crawley, et. al.             Informational                     [Page 23]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


4.3.1.1 Single RSVP VC per RSVP Reservation

   In this scheme, there is a parallel RSVP signalling VC for each RSVP
   reservation. This scheme results in twice the number of VCs, but
   means that RSVP signalling messages have the advantage of a separate
   VC.  This separate VC means that RSVP signalling messages have their
   own traffic contract and compliant signalling messages are not
   subject to dropping due to other noncompliant traffic (such as can
   happen with the scheme in section 4.3.1). The advantage of this
   scheme is its simplicity - whenever a data VC is created, a separate
   RSVP signalling VC is created.  The disadvantage of the extra VC is
   that extra ATM signalling needs to be done. Additionally, this scheme
   requires twice the minimum number of VCs and also additional latency,
   but is quite simple.

4.3.1.2 Multiplexed point-to-multipoint RSVP VCs

   In this scheme, there is a single point-to-multipoint RSVP signalling
   VC for each unique ingress router and unique set of egress routers.
   This scheme allows multiplexing of RSVP signalling traffic that
   shares the same ingress router and the same egress routers.  This can
   save on the number of VCs, by multiplexing, but there are problems
   when the destinations of the multiplexed point-to-multipoint VCs are
   changing.  Several alternatives exist in these cases, that have
   applicability in different situations. First, when the egress routers
   change, the ingress router can check if it already has a point-to-
   multipoint RSVP signalling VC for the new list of egress routers. If
   the RSVP signalling VC already exists, then the RSVP signalling
   traffic can be switched to this existing VC. If no such VC exists,
   one approach would be to create a new VC with the new list of egress
   routers. Other approaches include modifying the existing VC to add an
   egress router or using a separate new VC for the new egress routers.
   When a destination drops out of a group, an alternative would be to
   keep sending to the existing VC even though some traffic is wasted.
   The number of VCs used in this scheme is a function of traffic
   patterns across the ATM network, but is always less than the number
   used with the Single RSVP VC per data VC. In addition, existing best
   effort data VCs could be used for RSVP signalling. Reusing best
   effort VCs saves on the number of VCs at the cost of higher
   probability of RSVP signalling packet loss.  One possible place where
   this scheme will work well is in the core of the network where there
   is the most opportunity to take advantage of the savings due to
   multiplexing.  The exact savings depend on the patterns of traffic
   and the topology of the ATM network.







Crawley, et. al.             Informational                     [Page 24]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


4.3.1.3 Multiplexed point-to-point RSVP VCs

   In this scheme, multiple point-to-point RSVP signalling VCs are used
   for a single point-to-multipoint data VC.  This scheme allows
   multiplexing of RSVP signalling traffic but requires the same traffic
   to be sent on each of several VCs. This scheme is quite flexible and
   allows a large amount of multiplexing.

   Since point-to-point VCs can set up a reverse channel at the same
   time as setting up the forward channel, this scheme could save
   substantially on signalling cost.  In addition, signalling traffic
   could share existing best effort VCs.  Sharing existing best effort
   VCs reduces the total number of VCs needed, but might cause
   signalling traffic drops if there is congestion in the ATM network.
   This point-to-point scheme would work well in the core of the network
   where there is much opportunity for multiplexing. Also in the core of
   the network, RSVP VCs can stay permanently established either as
   Permanent Virtual Circuits (PVCs) or  as long lived Switched Virtual
   Circuits (SVCs). The number of VCs in this scheme will depend on
   traffic patterns, but in the core of a network would be approximately
   n(n-1)/2 where n is the number of IP nodes in the network.  In the
   core of the network, this will typically be small compared to the
   total number of VCs.

4.3.2 QoS for RSVP VCs

   There is an issue of what QoS, if any, to assign to the RSVP
   signalling VCs. For other RSVP VC schemes, a QoS (possibly best
   effort) will be needed.  What QoS to use partially depends on the
   expected level of multiplexing that is being done on the VCs, and the
   expected reliability of best effort VCs. Since RSVP signalling is
   infrequent (typically every 30 seconds), only a relatively small QoS
   should