rfc2382.txt

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

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


                             Data Flow ==========>

                     +-----+
                     |     |      -------------->  +----+
                     | Src |    -------------->    | R1 |
                     |    *|  -------------->      +----+
                     +-----+       QoS VCs
                          /\
                          ||
                      VC  ||
                      Initiator

                    Figure 1: Data Flow VC Initiation

   While RSVP is receiver oriented, ATM is sender oriented.  This might
   seem like a problem but the sender or ingress point receives RSVP
   RESV messages and can determine whether a new VC has to be set up to
   the destination or egress point.

2.1.1.3 Point to MultiPoint

   In order to provide QoS for IP multicast, an important feature of
   RSVP, data flows must be distributed to multiple destinations from a
   given source.  Point-to-multipoint VCs provide such a mechanism.  It
   is important to map the actions of IP multicasting and RSVP (e.g.
   IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) to add party and drop party
   functions for ATM.  Point-to-multipoint VCs as defined in UNI 3.x and
   UNI 4.0 have a single service class for all destinations.  This is
   contrary to the RSVP "heterogeneous receiver" concept.  It is
   possible to set up a different VC to each receiver requesting a
   different QoS, as shown in Figure 2. This again can run into scaling
   and resource problems when managing multiple VCs on the same
   interface to different destinations.


















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


                                    +----+
                           +------> | R1 |
                           |        +----+
                           |
                           |        +----+
              +-----+ -----+   +--> | R2 |
              |     | ---------+    +----+  Receiver Request Types:
              | Src |                       ---->  QoS 1 and QoS 2
              |     | .........+    +----+  ....>  Best-Effort
              +-----+ .....+   +..> | R3 |
                           :        +----+
                       /\  :
                       ||  :        +----+
                       ||  +......> | R4 |
                       ||           +----+
                     Single
                  IP Multicast
                     Group

                    Figure 2: Types of Multicast Receivers

   RSVP sends messages both up and down the multicast distribution tree.
   In the case of a large ATM cloud, this could result in a RSVP message
   implosion at an ATM ingress point with many receivers.

   ATM 4.0 expands on the point-to-multipoint VCs by adding a Leaf
   Initiated Join (LIJ) capability. LIJ allows an ATM end point to join
   into an existing point-to-multipoint VC without necessarily
   contacting the source of the VC.  This can reduce the burden on the
   ATM source point for setting up new branches and more closely matches
   the receiver-based model of RSVP and IP multicast.  However, many of
   the same scaling issues exist and the new branches added to a point-
   to-multipoint VC must use the same QoS as existing branches.

2.1.1.4 Multicast Servers

   IP-over-ATM has the concept of a multicast server or reflector that
   can accept cells from multiple senders and send them via a point-to-
   multipoint VC to a set of receivers.  This moves the VC scaling
   issues noted previously for point-to-multipoint VCs to the multicast
   server.  Additionally, the multicast server will need to know how to
   interpret RSVP packets or receive instruction from another node so it
   will be able to provide VCs of the appropriate QoS for the RSVP
   flows.







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


2.1.2 Hop-by-Hop vs. Short Cut

   If the ATM "cloud" is made up a number of logical IP subnets (LISs),
   then it is possible to use "short cuts" from a node on one LIS
   directly to a node on another LIS, avoiding router hops between the
   LISs. NHRP [4], is one mechanism for determining the ATM address of
   the egress point on the ATM network given a destination IP address.
   It is a topic for further study to determine if significant benefit
   is achieved from short cut routes vs. the extra state required.

2.1.3 Future Models

   ATM is constantly evolving.  If we assume that RSVP and IntServ
   applications are going to be wide-spread, it makes sense to consider
   changes to ATM that would improve the operation of RSVP and IntServ
   over ATM.  Similarly, the RSVP protocol and IntServ models will
   continue to evolve and changes that affect them should also be
   considered.  The following are a few ideas that have been discussed
   that would make the integration of the IntServ models and RSVP easier
   or more complete.  They are presented here to encourage continued
   development and discussion of ideas that can help aid in the
   integration of RSVP, IntServ, and ATM.

2.1.3.1 Heterogeneous Point-to-MultiPoint

   The IntServ models and RSVP support the idea of "heterogeneous
   receivers"; e.g., not all receivers of a particular multicast flow
   are required to ask for the same QoS from the network, as shown in
   Figure 2.

   The most important scenario that can utilize this feature occurs when
   some receivers in an RSVP session ask for a specific QoS while others
   receive the flow with a best-effort service.  In some cases where
   there are multiple senders on a shared-reservation flow (e.g., an
   audio conference), an individual receiver only needs to reserve
   enough resources to receive one sender at a time.  However, other
   receivers may elect to reserve more resources, perhaps to allow for
   some amount of "over-speaking" or in order to record the conference
   (post processing during playback can separate the senders by their
   source addresses).

   In order to prevent denial-of-service attacks via reservations, the
   service models do not allow the service elements to simply drop non-
   conforming packets.  For example, Controlled Load service model [7]
   assigns non-conformant packets to best-effort status (which may
   result in packet drops if there is congestion).





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


   Emulating these behaviors over an ATM network is problematic and
   needs to be studied.  If a single maximum QoS is used over a point-
   to-multipoint VC, resources could be wasted if cells are sent over
   certain links where the reassembled packets will eventually be
   dropped.  In addition, the "maximum QoS" may actually cause a
   degradation in service to the best-effort branches.

   The term "variegated VC" has been coined to describe a point-to-
   multipoint VC that allows a different QoS on each branch.  This
   approach seems to match the spirit of the Integrated Service and RSVP
   models, but some thought has to be put into the cell drop strategy
   when traversing from a "bigger" branch to a "smaller" one.  The
   "best-effort for non-conforming packets" behavior must also be
   retained.  Early Packet Discard (EPD) schemes must be used so that
   all the cells for a given packet can be discarded at the same time
   rather than discarding only a few cells from several packets making
   all the packets useless to the receivers.

2.1.3.2 Lightweight Signalling

   Q.2931 signalling is very complete and carries with it a significant
   burden for signalling in all possible public and private connections.
   It might be worth investigating a lighter weight signalling mechanism
   for faster connection setup in private networks.

2.1.3.3 QoS Renegotiation

   Another change that would help RSVP over ATM is the ability to
   request a different QoS for an active VC.  This would eliminate the
   need to setup and tear down VCs as the QoS changed.  RSVP allows
   receivers to change their reservations and senders to change their
   traffic descriptors dynamically.  This, along with the merging of
   reservations, can create a situation where the QoS needs of a VC can
   change.  Allowing changes to the QoS of an existing VC would allow
   these features to work without creating a new VC.  In the ITU-T ATM
   specifications [24,25], some cell rates can be renegotiated or
   changed.  Specifically, the Peak Cell Rate (PCR) of an existing VC
   can be changed and, in some cases, QoS parameters may be renegotiated
   during the call setup phase. It is unclear if this is sufficient for
   the QoS renegotiation needs of the IntServ models.

2.1.3.4 Group Addressing

   The model of one-to-many communications provided by point-to-
   multipoint VCs does not really match the many-to-many communications
   provided by IP multicasting.  A scaleable mapping from IP multicast
   addresses to an ATM "group address" can address this problem.




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


2.1.3.5 Label Switching

   The MultiProtocol Label Switching (MPLS) working group is discussing
   methods for optimizing the use of ATM and other switched networks for
   IP by encapsulating the data with a header that is used by the
   interior switches to achieve faster forwarding lookups.  [22]
   discusses a framework for this work.  It is unclear how this work
   will affect IntServ and RSVP over label switched networks but there
   may be some interactions.

2.1.4 QoS Routing

   RSVP is explicitly not a routing protocol.  However, since it conveys
   QoS information, it may prove to be a valuable input to a routing
   protocol that can make path determinations based on QoS and network
   load information.  In other words, instead of asking for just the IP
   next hop for a given destination address, it might be worthwhile for
   RSVP to provide information on the QoS needs of the flow if routing
   has the ability to use this information in order to determine a
   route.  Other forms of QoS routing have existed in the past such as
   using the IP TOS and Precedence bits to select a path through the
   network.  Some have discussed using these same bits to select one of
   a set of parallel ATM VCs as a form of QoS routing.  ATM routing has
   also considered the problem of QoS routing through the Private
   Network-to-Network Interface (PNNI) [26] routing protocol for routing
   ATM VCs on a path that can support their needs.  The work in this
   area is just starting and there are numerous issues to consider.
   [23], as part of the work of the QoSR working group frame the issues
   for QoS Routing in the Internet.

2.2 Reliance on Unicast and Multicast Routing

   RSVP was designed to support both unicast and IP multicast
   applications.  This means that RSVP needs to work closely with
   multicast and unicast routing.  Unicast routing over ATM has been
   addressed [10] and [11].  MARS [5] provides multicast address
   resolution for IP over ATM networks, an important part of the
   solution for multicast but still relies on multicast routing
   protocols to connect multicast senders and receivers on different
   subnets.

2.3 Aggregation of Flows

   Some of the scaling issues noted in previous sections can be