rfc1946.txt

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

   at the edge of the ATM networks must generate and regenerate
   endpoint-based signaling messages on behalf of the host reservation
   agents.  In particular, CONNECT and ACCEPT messages and their
   associated flowspecs must be regenerated.  Refer to Section 5 for
   details on the QoS mappings and on which QoS parameters can be
   recreated for the generated flowspecs.

   This approach is worth revisiting as an optimal signaling method in
   pure ATM network environments once ATM signaling capabilities expand.

   However, for heterogeneous networks,  other signaling mechanisms may
   be more appropriate.

4.2 In-Band Reservation Signaling

   In-Band Reservation Signaling is the easiest signaling mechanism to
   implement.  When the applications requests a reservation, the
   reservation agent simply sets up ATM virtual circuits to the
   endpoints with the   QoS specified in the CONNECT request.  When
   ACCEPTed, all subsequent data transmissions proceed  on the virtual
   circuits.

   Once again, to support multicast, the reservation agent must create
   individual point-to-point virtual circuits to the targets which are



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


   directly connected to the ATM network, as well as to routers which
   can access downstream targets.

   Since signaling is done in-band, all reservation signaling messages
   can be passed between agents.  However, some minimal additional
   bandwidth must be allocated in the Q.2931 SETUP to allow for the
   signaling messages themselves.

   Note that the primary disadvantage to In-Band Reservation Signaling
   is the fact that it does not make use of  the multipoint capabilities
   of ATM and will thus overreserve ATM network bandwidth and create a
   larger than necessary number of virtual circuits.

4.3 Dedicated Reservation Signaling Virtual Circuits

   One mechanism that can be used to take advantage of the full data
   transmission capabilities of ATM networks is to use Dedicated Virtual
   Circuits for reservation signaling.  This guarantees a two-way
   signaling pipe between the endpoints in a connection while enabling
   the data transmission to take advantage of the multipoint
   capabilities of ATM.  Data and Signaling are done over separate
   virtual circuits.

   When an application requests a reservation, the reservation agent
   reviews the list of targets in the CONNECT request.  For any targets
   which have no current signaling virtual circuits established, the
   agent establishes UBR (unspecified bit rate) virtual circuits and
   forwards the CONNECT message to the targets over these virtual
   circuits. ATMARP is used to resolve any endpoint addresses.  For any
   targets for which there already exist signaling virtual circuits, the
   agent simply forwards the CONNECT message over the existing virtual
   circuit.

   Once an ACCEPT message is received, the agent issues a Q.2931 SETUP
   to the associated target.  Upon receipt of a CONNECTACK, data can
   begin to flow.  As additional ACCEPTs are received, the Q.2931
   ADDPARTY message is used to add a target to the multicast and
   multipoint connection.  Depending on the cause of any ADDPARTY
   failure, the agent may attempt to establish a dedicated point-to-
   point virtual circuit to complete the multicast group.

   DISCONNECT requests result in  Q.2931 DROPPARTY messages and will
   cause a member to be dropped from a multicast and multipoint
   connection.  When all targets are dropped from a multipoint
   connection, a RELEASE can be issued to take down the virtual circuit.

   Signaling virtual circuits are shared among reservations while data
   circuits are dedicated to a particular  reservation.   Once all



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


   reservations to a given endpoint are terminated, the signaling
   virtual circuit to that endpoint can be RELEASEd.

   Note that this approach  would allow the NSAP address to be passed as
   user data in the ACCEPT message to enable a kernel-based reservation
   protocol to establish the dedicated data circuit.  In addition,
   because the connectivity to the endpoint is identical to that of the
   data circuit, this approach assures the fact that accumulated
   information in the flowspecs retains it validity.

4.4 Reservation Signaling via IP over ATM or LAN Emulation

   As described in the previous section, it would be possible to set up
   unique SVCs for SCMP signaling, however, since the streaming,
   connection-oriented data transport offered by ST-2 is intended to be
   complementary to IP and other connectionless protocol
   implementations, it would be simpler and more elegant to simply use
   classical IP over ATM (RFC 1577) mechanisms, or to use LAN Emulation.
   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 applications that do not need specific QoS and bandwidth
   provisioning, makes this the most straightforward (if not performance
   optimal) solution for signaling.  Once an end-to-end acceptance of a
   reservation request is completed via normal LAN or IP transmission,
   then a unique direct virtual circuit can be established for each data
   flow.

   If LAN Emulation is used, as long as the ST-2 implementation allows
   for different paths for SCMP and data, there would be no changes to
   the signaling mechanisms employed by the reservation agent.

   For IP over ATM, all SCMP messages would be encapsulated in IP as
   described in both RFC 1190 and RFC 1819.  This is required because
   current ATM drivers will not accept Ipv5 packets, and most drivers do
   not provide direct access to the shared signaling virtual circuits
   used for IP.

   In either case, LAN Emulation or IP over ATM, the reservation agent
   would handle SCMP messages as it normally does.  However, once the
   first ACCEPT is received for  a reservation request, a dedicated
   virtual circuit is established for the data flow.  Subsequent ACCEPTs
   will result in the use of ADDPARTY to add multicast targets to the
   multipoint virtual circuit.  In fact, processing of
   multipoint/multicast is identical to that described in section 4.3.

   Once again, the use of an out-of-band signaling mechanism makes it
   possible to carry the NSAP address of the target in the ACCEPT
   message.



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


   One potential drawback to using LAN Emulation or SCMP messages
   encapsulated in IP over ATM, is the fact that there is no guarantee
   that the connectivity achieved to reach the target via signaling has
   any relationship to the data path.  This means that accumulated
   values in the flowspec may be rendered useless.

   In addition, it is possible that the targets will actually  reside
   outside the ATM network.  That is, there may be no direct ATM access
   to the Targets and it may be difficult to identify ATM addresses of
   the associated ATM connected routers.  This approach will involve
   some additional complexity in routing to the targets.  However, since
   ST-2 is intended to run with IP, if ATM vendors would accept IPv5
   packets or would allow direct access to the IP over ATM signaling
   virtual circuits, this approach would be optimal in minimizing the
   number of virtual circuits required.

4.5 Summary of Reservation  Signaling Approaches

   Embedded Reservation Signaling (section 4.1) is ideal for homogeneous
   ATM connections, but  requires extensions to existing ATM signaling
   to support multipoint connections.  In-Band Reservation Signaling
   (section 4.2) is the easiest to implement, but cannot employ
   multipoint connections either.

   Perhaps the simplest way to do this is similar to what is suggested
   in [6]: separate the reservation signaling from the actual data
   flows, mapping the data flows directly to ATM circuits while doing
   the signaling separately.

   While there is significant complexity in doing this for IP traffic
   and RSVP, the ST2 protocols lend themselves to this quite well.  In
   fact, because SCMP reservation signaling results in streaming,
   multicast connections, the 'Shortcut' mechanism described in [6],
   which can bypass routers where direct ATM connections are possible,
   is automatically available to ST2 streams.

   Using Reservation Signaling over LAN Emulation or IP over ATM
   (section 4.4) is one multipoint-capable approach  to implement in
   hosts since most ATM drivers shipping today provide both IP over ATM
   and LAN Emulation, as well as associated address resolution
   mechanisms. However, it is not complete in its ability to accurately
   depict flowspec parameters or to resolve host ATM addresses. In
   addition, to be optimal, ATM vendors would either have to support
   IPv5 in their drivers or allow direct access to the IP signaling
   virtual circuits.  Thus the current ideal approach to implementation
   of the ST2 protocols over ATM is to use shared Dedicated Reservation
   Signaling Virtual Circuits (section 4.3) for signaling of
   reservations, and then to establish appropriate multipoint ATM



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


   virtual circuits for the data flows.

5.0 Mapping of Reservation QoS to ATM QoS

   QoS negotiation in ST-2 (and ST-2+) is done via a two-way
   negotiation.

   The origin proposes a QoS for the connection in a Flow Specification
   (Flowspec) associated with the CONNECT message.  Most of the
   network-significant QoS parameters in the Flowspec include both a
   minimum and a desired value.  Each ST agent along the path to the
   Target validates its ability to provide the specified QoS (at least
   the minimum value for each), updates certain values in the Flowspec,
   and propagates the CONNECT until it reaches the Target.  The Target
   can either ACCEPT the Flowspec or REFUSE it if it cannot meet at
   least the minimum QoS requirements.  Negotiation takes place as part
   of the process in that the Target can specify changes to the desired
   QoS values as long as the new value meets at least the minimum
   requirements specified by the Origin system.  In addition, both the
   Target and the Origin can assess actual network performance by
   reviewing the values that are accumulated along the path.

   The primary Reservation QoS parameters that impact an ATM network
   are:

ST-2 (RFC 1190)                                 ST-2+ (RFC 1819)

Desired PDU Bytes,                              Desired Message Size,
Limit on PDU Bytes (minimum).                   Limit on Message Size.

Desired PDU Rate,                               Desired Rate,
Limit on PDU Rate (minimum).                    Limit on Rate.
Minimum Transmission Rate in Bytes.

Limit on Delay (maximum).                       Desired Delay,
                                                Limit on Delay.
Maximum Bit Error Rate.

Accumulated Delay.
Accumulated Delay Variance (Jitter).

Q.2931 ATM signaling offers the following QoS parameters:

-       Cumulative Transit Delay,
-       Maximum End to End Transit Delay.

-       Forward Peak Cell Rate (PCR),
-       Backward Peak Cell Rate (PCR).



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


-       Forward Maximum CPCS-SDU size,
-       Backward Maximum CPCS-SDU size.

-       Forward QoS Class,
-       Backward QoS Class.

-       B-LLI (one byte user protocol information).

   As previously noted, reservation protocols (ST and RSVP) make QoS
   reservations in one direction only. Thus, depending on the type of
   signaling used (see Section 4), the 'Backward' ATM parameters may not
   be useful.  In particular, if Multipoint ATM connections are used to
   map multicast reservations, these parameters are not available.

   However, it would be possible to implement a multiplexing scheme to
   enable reservations to share bi-directional point-to-point ATM
   connections if the reservation agent creates a split/merge point at
   the ATM boundary and sets up only point-to-point VC connections to
   targets.

   The CPCS-SDU parameters are AAL Parameters which are used by the AAL
   entity to break packets into cells.  As such, these parameters are
   not modified by the network and could conceivably be used for
   additional end-to-end signaling, along with the B-LLI.

   Finally, QoS Class is somewhat limited in its use and implementation.
   While IP over ATM recommends use of Class 0 (Unspecified QoS), this
   is not sufficient for guaranteed connections.  Instead, Class 1 with
   CLP=0 will provide at least minimum QoS services for the traffic.

5.1 CPCS-SDU Size Computation

   The CPCS-SDU size computation is the easiest QoS mapping.  Since ST-2
   does not require a Service Specific Convergence Sublayer (SSCS), if
   AAL 5 is used, the ST packet size plus 8 bytes  (for the AAL 5
   Trailer) will be the CPCS-SDU size. Note that the ST-2 packet size
   also includes an 8-byte header for ST-2.  Thus the CPCS-SDU size is:

        CPCS-SDUsize = PDUbytes + 8 + 8.