rfc1946.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,180 行 · 第 1/4 页

   in the current version of ATM signaling with Q.2931 and UNI 3.1.
   Among these are:

   1) Addressing.
   2) Changes to Bandwidth and QoS.
   3) Multicasting.
   4) Receiver initiated JOINs to multicast groups.
   5) Computation of certain QoS parameters.
   6) Use of HELLOs.

   The degree of difficulty in supporting these functions is dependent
   on the signaling mechanism chosen.  See Section 4 for descriptions of
   possible signaling approaches and their respective impact on the
   features listed above.

3.1 Addressing

   Of course mapping an Internet address to ATM address is always
   problematic.  It would be possible to set up a well known ARP server
   to resolve the IP addresses of targets.  However, the widespread
   deployment of IP over ATM and LAN emulation in host-based ATM
   drivers, and the assumption that most host systems will be running
   some  IP applications that do not need specific QoS and bandwidth
   provisioning, suggests that  use of ARP facilities provided by IP
   over ATM and LAN Emulation  is the most obvious choice for address
   resolution.

   It should be noted that ATMARP returns the ATM address.  For some
   implementations (particularly kernel-based protocols), an NSAP
   address is also required.  Since these addresses are often difficult
   to get from the ATM network itself in advance of the connection, it
   may be necessary to invoke out-of-band signaling mechanisms to pass
   this address, or it may be better to create an NSAP address server.

3.2 Changes to Bandwidth and QoS

   Both ST-2 and ST-2+ allow the origin to dynamically change the QoS
   and Bandwidth of a particular stream.  At this time Q.2931 and UNI
   3.1 do not support this feature. Until this capability is available,



Jackowski                    Informational                      [Page 6]

RFC 1946              Native ATM Support for ST2+               May 1996


   full support of the SCMP CHANGE message for dedicated ATM circuits
   (one reservation = one ATM circuit) can only be implemented  by
   tearing down the existing VC for a stream and establishing a new one
   if efficient use of ATM resources are to be preserved.

   Of course, the CHANGE message can simply be passed across the ATM
   virtual circuit to the hosts or routers. This would allow the hosts
   to relax resource requirements locally, and permit routers to relax
   access to downstream circuits, but the ATM VC itself, would still
   retain excessive bandwidth.

   In addition, if the implementation allows sharing of virtual circuits
   by multiple streams, the bandwidth/QoS of individual streams within
   the VC can be CHANGEd.

3.3 Multicasting

   ST-2 and ST-2+ support origin-oriented multicasting.  That is, the
   origin of a stream explicitly specifies the addresses of the targets
   it wants involved in the connection.  In addition, the origin can Add
   or drop targets as desired.  Aside from receiver-initiated JOINs
   (discussed in section 3.4), there is a one to one mapping between
   ST-2 multicast and ATM multipoint connections.  Origin-initiated
   additions can be accomplished through an ADDPARTY, and drops can be
   done through DROPPARTY.

   A key goal in implementation of a native ATM protocol is to ensure
   consistent implementation for unicast and multicast data transfers.
   One difficulty in doing this with ATM Virtual Circuits is the fact
   that point-to-point circuits are duplex, while multipoint circuits
   are simplex.  This means that for multicast connections to be mapped
   to multipoint ATM Virtual Circuits, any two-way, end-to-end signaling
   must be done out of band.  An alternative is to  let the local
   reservation agent act as a split/merge point for the connection by
   establishing point-to-point Virtual Circuits for each member of the
   multicast group directly connected to the ATM network.  For multicast
   group members not directly connected to the ATM network, traffic can
   be multicast to the router connected at the edge across a single
   virtual circuit associated with the reservation.

   Section 4 describes alternative mechanisms for implementing
   signaling.

   Included in each discussion is the optimal means for mapping
   multicast to ATM  point-to-point or multipoint circuits.

   Note that the fact that ST-2 does not rely on IP multicast is a
   strong advantage in implementation of a native protocol for ATM.  The



Jackowski                    Informational                      [Page 7]

RFC 1946              Native ATM Support for ST2+               May 1996


   one-to-one mapping of ST-2 multicast connections to ATM multipoint
   virtual circuits minimizes the number of circuits required to support
   large multicast groups.

3.4 Receiver Initiated JOINs to Multicast Groups

   ST-2+ provides an in-band mechanism to permit receivers to join an
   existing stream.  Based on an origin-established authorization level,
   the JOIN can be refused immediately, can be allowed with notification
   of the origin, or can be allowed without notifying the origin.  This
   capability is made available through a new SCMP JOIN message.  If the
   receiver knows the IP address of the origin and the Stream ID, he can
   join the stream if authorized to do so.

   Note that since the JOIN flows from the receiver to the origin, there
   will be issues in trying to  support this feature with Q.2931 and UNI
   3.1. The JOIN may have to be sent out of band depending on the
   signaling mechanism chosen (section 4) because of the uni-directional
   flow for point to multipoint ATM connections.  This is supposed to
   change with availability of UNI 4.0.

   ST-2 did not support receiver initiated JOINs (unlike ST-2+).
   However, most implementations created an out-of-band, or SCMP
   extension to support this facility.  Again, depending on the SCMP
   signaling mechanism chosen, this feature may be difficult to support.

3.5 Computation of QoS Parameters

   The recommended flow specifications (flowspecs) for ST-2 and ST-2+
   include parameters that are not currently available to ATM virtual
   circuits through Q.2931 and  UNI 3.1.  The mapping of packet rate to
   cell rate,  packet delay to cell delay, and other translatable QoS
   parameters is described in section 5.  However,  the ST-2 flowspecs
   also include parameters like accumulated end-to-end delay and
   accumulated jitter.  These parameters assume that the SCMP messages
   follow the same path as the data.  Depending on the signaling
   mechanism chosen, this may not be true with ATM and thus certain QoS
   parameters may be rendered useless.

   It should also be noted that since ST-2 connections are simplex, all
   QoS parameters are specified separately for each direction of data
   transfer.  Thus two connections and two QoS negotiations are required
   for a duplex connection.  To take advantage of the full duplex nature
   of point-to-point ATM connections, special multiplexing of ST
   connections would be required by ST-2 agents.






Jackowski                    Informational                      [Page 8]

RFC 1946              Native ATM Support for ST2+               May 1996


3.6 Use of HELLOs

   Both ST-2 and ST-2+ support HELLO messages.  HELLOs are intended to
   assure that the neighboring agent is alive.  Failure to respond to a
   HELLO indicates that the connection is down and that the reservation
   for that particular link should be freed.

   While the ATM network will notify an ST-2 agent if the network
   connection is down, there is still the possibility that the
   connection is intact but that the ST-2 agent itself is down.
   Knowledge of the neighboring agent's status is increasingly important
   when multiple ST-2 connections share virtual circuits, when the
   neighboring agents are routers, and when there are multiple dedicated
   virtual circuits between agents.

   As such, HELLO is a desirable feature.  Note that some signaling
   schemes (section 4), provide less than optimal support for HELLO.

4.0 Reservation Signaling with ATM

   Use of Permanent Virtual Circuits (PVCs) for reservation signaling
   presents no problem for ST-2, ST-2+, or RSVP.  Each circuit is
   considered to be a dedicated link to the next hop.  If the PVCs are
   to be shared, reservation protocols can divide and regulate the
   bandwidth just as they would with any other link type.

   Where ATM connections become more interesting is when the ATM network
   takes on the role of an extended LAN or internet.  To do this,
   Switched Virtual Circuits are used to establish dynamic connections
   to various endpoints and routers.  The ITU-TS Q.2931 SETUP message is
   used to request a connection from the network with specific bandwidth
   and QoS requirements, and a CONNECT message is received by the origin
   to indicate that connection establishment is complete.

   For IP over ATM and LAN Emulation, SVCs are established between
   endpoints and data traffic for a given destination shares the SVCs.
   There is no mechanism to allow specific QoS guarantees for the
   traffic, nor is there a mechanism to set up virtual circuits with
   specific bandwidth and QoS for a particular type of traffic.  This is
   what reservation protocols will attempt to do.  The goal is to use
   reservations to request establishment of individual virtual circuits
   with matching bandwidth and QoS for each reservation.  This will
   guarantee the requirements of the application while taking full
   advantage of the ATM network's capabilities.

   There are four possible mechanisms to perform reservation signaling
   over ATM:




Jackowski                    Informational                      [Page 9]

RFC 1946              Native ATM Support for ST2+               May 1996


   1) Embedding  reservation signaling equivalents within the ATM Q.2931
      controls.
   2) Signaling in-band with the data.
   3) Signaling over dedicated signaling VCs.
   4) Implicitly sharing existing VCs for IP over ATM or LAN Emulation.

   Note that ATM circuits are not necessarily reliable.  As such, the
   reliability mechanisms provided by SCMP must be maintained to assure
   delivery of all reservation signaling messages.

4.1 Embedded Reservation Signaling Equivalents within ATM Q.2931
    Controls

   The basic idea in embedding reservation signaling within the ATM
   controls is to use the Q.2931 SETUP and CONNECT messages to establish
   both reservations and dedicated data paths (virtual circuits) across
   the ATM network.  This eliminates the need for dedicated signaling
   channels, in-band signaling, or out of band mechanisms to communicate
   between endpoints.  Since SETUP and CONNECT include bandwidth and QoS
   information, the basic concept is sound.  In fact, this approach will
   speed network connection by preventing multiple passes at
   establishing a reservation and associated connection.  This normally
   results from the fact that most higher layer protocols (network and
   transport) first require a link to signal their connection
   requirements.  As such,  with ATM, the ATM virtual circuit must be
   established before the network  and/or transport protocols can do
   their own signaling.

   Embedded reservation signaling allows the reservation information to
   be carried in the SETUP and CONNECT messages, allowing the
   reservation protocol to do its signaling simultaneously with the ATM
   signaling.

   [7] describes a clever way of combining the reservation signaling
   with the ATM control plane signaling for ST-2.  This 'simultaneous
   connection establishment' process will optimize the establishment of
   circuits and minimize connection setup time while simultaneously
   eliminating unnecessary network layer signaling in ST-2.  To be
   effective, [7] requires enhancements to Q.2931 signaling and to the
   ST-2 protocol implementations.  In addition, it currently only
   applies to point-to-point connections and will not work with
   multipoint largely due to the simplex nature of multipoint
   communication in current ATM implementations.

   Implementation of multicast for Embedded Reservation Signaling is
   done as described above: the reservation agent at the edge of the ATM
   network must create point-to-point virtual circuits for each target
   that is directly connected to the ATM network, and for each router



Jackowski                    Informational                     [Page 10]

RFC 1946              Native ATM Support for ST2+               May 1996


   that supports downstream targets.  This ensures two-way signaling
   between targets and the origin.

   Signaling itself is quite simple:

        CONNECT maps directly to one or more (multicast) Q.2931
                SETUPs and CONNECTs.
        ACCEPT maps directly to Q.2931 CONNECTACK.
        CHANGE/CHANGE REQUEST are  not supported.
        DISCONNECT maps directly to Q.2931 RELEASE.
        HELLOs are not needed.

   Unfortunately, the flowspec in the reservation protocol CONNECT
   message cannot be passed across the ATM network in the signaling
   messages and thus must be regenerated by the receiving agent.

   In addition, User Data, which can be sent in most SCMP messages
   cannot be supported without substantial changes to current Q.2931
   signaling.

   One of the additional complexities with embedding the reservation
   signaling occurs in heterogeneous networks.  Since ATM signaling only
   operates point to point across the ATM network itself, if the
   endpoints reside on other types of networks or subnets, the routers