As per Relevance of the word practice, we have this rfc below:
Network Working Group L.
Request for Comments: 2379 FORE
BCP: 24 August 1998
Category: Best Current
RSVP over ATM Implementation
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This memo presents specific implementation guidelines for
RSVP over ATM switched virtual circuits (SVCs). The general
is discussed in [6]. Implementation requirements are discussed
[2]. Integrated Services to ATM service mappings are covered in [3].
The full set of documents present the background and
needed to implement Integrated Services and RSVP over ATM
1.
This memo discusses running IP over ATM in an environment where
are used to support QoS flows and RSVP is used as the internet
QoS signaling protocol. It applies when using CLIP/ION, LANE2.0
MPOA methods for supporting IP over ATM. The general issues
to running RSVP[4] over ATM have been covered in several
including [6] and other earlier work. This document is intended as
companion to [6,2] and as a guide to implementers. The reader
be familiar with both documents
This document provides a recommended set of functionality
implementations using ATM UNI3.x and 4.0, while allowing for
sophisticated approaches. We expect some vendors to
provide some of the more sophisticated approaches described in [6],
and some networks to only make use of such approaches.
recommended set of functionality is defined to ensure
and interoperability between different implementations.
for RSVP over ATM implementations are provided in [2].
Berger Best Current Practice [Page 1]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
This document uses the same terms and assumption stated in [2].
Additionally, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
"OPTIONAL" in this document are to be interpreted as described in
2119 [5].
2. Implementation
This section provides implementation guidelines for implementation
RSVP over ATM. Several recommendations are common for all,
sessions, both unicast and multicast. There are also
that are unique to unicast and multicast session types
2.1 RSVP Message VC
The general issues related to which VC should be used for
messages is covered in [6]. It discussed several
options including: mixed control and data, single control VC
session, single control VC multiplexed among sessions, and
VCs multiplexed among sessions. QoS for control VCs was
discussed. The general discussion is not repeated here and [6]
should be reviewed for detailed information
RSVP over ATM implementations SHOULD send RSVP control (messages
over the best effort data path, see figure 1. It is permissible
allow a user to override this behavior. The stated
minimizes VC requirements since the best effort data path will
to exist in order for RSVP sessions to be established and in
for RSVP reservations to be initiated. The specific best
paths that will be used by RSVP are: for unicast, the same VC used
reach the unicast destination; and for multicast, the same VC that
used for best effort traffic destined to the IP multicast group
Note that for multicast there may be another best effort VC that
used to carry session data traffic, i.e., for data that is both
the multicast group and matching a sessions protocol and port
Berger Best Current Practice [Page 2]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
Data Flow ==========>
QoS
+-----+ --------------> +----+
| | --------------> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <-----------------> +----+
/\
||
||
RSVP
Figure 1: RSVP Control Message VC
The disadvantage of this approach is that best effort VCs may
provide the reliability that RSVP needs. However the best
path is expected to satisfy RSVP reliability requirements in
networks. Especially since RSVP allows for a certain amount of
loss without any loss of state synchronization
2.2
As discussed in [6], data associated with multiple RSVP sessions
be sent using the same shared VCs. Implementation of
"aggregation" models is still a matter for research. Therefore,
over ATM implementations SHOULD use independent VCs for each
reservation
2.3 Short-
Short-cuts allow ATM attached routers and hosts to directly
point-to-point VCs across LIS boundaries, i.e., the VC end-points
on different IP subnets. Short-cut support for unicast traffic
been defined in [7] and [1]. The ability for short-cuts and RSVP
interoperate has been raised as a general question. The area
concern is the ability to handle asymmetric short-cuts.
how RSVP can handle the case where a downstream short-cut may
have a matching upstream short-cut. In this case, which is shown
figure 2, PATH and RESV messages following different paths
Berger Best Current Practice [Page 3]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
______
/ \
+-------- / Router \ <-------+
| \ / | <....... RESVs
| \______/ | Hop-by-hop
| |
| |
V QoS VCs |
+-----+ ==============> +----+
| | ==============> | |
| Src | | R1 |
| | Best Effort VC(s) | |
+-----+ <=================> +----+
/\
:: Data Paths
:: ----> Hop-by-hop (routed
PATHs and Data ====> Short-
Follow Short-
Figure 2: Asymmetric RSVP Message Forwarding With ATM Short-
Examination of RSVP shows that the protocol already
mechanisms that allows support of the asymmetric paths.
mechanism is the same one used to support RESV messages arriving
the wrong router and the wrong interface. RSVP messages are
processed when they arrive at the proper interface. When
arrive on the wrong interface, they are forwarded by RSVP.
proper interface is indicated in the NHOP object of the message. So
existing RSVP mechanisms will support the asymmetric paths that
occur when using short-cuts
The short-cut model of VC establishment still poses several
when running with RSVP. The major issues are dealing with
best effort short-cuts, when to establish short-cuts, and QoS
short-cuts. These issues will need to be addressed by
implementations
The key issue to be addressed by RSVP over ATM implementations
when to establish a short-cut for a QoS data flow. RSVP over
implementations SHOULD simply follow best effort traffic. When
short-cut has been established for best effort traffic to
destination or next-hop, that same end-point SHOULD be used
setting up RSVP triggered VCs for QoS traffic to the same
or next-hop. This will happen naturally when PATH messages
forwarded over the best effort short-cut. Note that in
Berger Best Current Practice [Page 4]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
approach, when best effort short-cuts are never established,
triggered QoS short-cuts will also never be established
2.4 Data VC Management for Heterogeneous
Heterogeneous sessions can only occur with multicast RSVP sessions
The issues relating to data VC management of heterogeneous
are covered in detail in [6] and are not repeated in this document
In summary, heterogeneity occurs when receivers request
levels of QoS within a single session and also when some receivers
not request any QoS. Both types of heterogeneity are shown in
3.
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
IP
Figure 3: Types of Multicast
[6] provides four models for dealing with heterogeneity:
heterogeneity, limited heterogeneity, homogeneous, and
homogeneous models. The key issue to be addressed by
implementation is providing requested QoS downstream. One of, or
combination of, the discussed models [6] may be used to provide
requested QoS. Unfortunately, none of the described models is
right answer for all cases. For some networks, e.g. public WANs,
is likely that the limited heterogeneous model or a hybrid limited
full heterogeneous model will be desired. In other networks, e.g
LANs, it is likely that a the modified homogeneous model will
desired
Berger Best Current Practice [Page 5]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
Since there is not one model that satisfies all cases
implementations SHOULD implement one of either the
heterogeneity model or the modified homogeneous model
Implementations SHOULD support both approaches and provide
ability to select which method is actually used, but are not
to do so
3. Security
The same considerations stated in [4] and [8] apply to this document
There are no additional security issues raised in this document
4.
This work is based on earlier drafts and comments from the
working group. The author would like to acknowledge
contribution, most notably Steve Berson who coauthored one of
drafts
5. Author's
Lou
FORE
1595 Spring Hill
5th
Vienna, VA 22182
Phone: +1 703-245-4527
EMail: lberger@fore.
Berger Best Current Practice [Page 6]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
[1] The ATM Forum, "MPOA Baseline Version 1", May 1997.
[2] Berger, L., "RSVP over ATM Implementation Requirements",
RFC 2380, August 1998.
[3] Borden, M., and M. Garrett, "Interoperation of Controlled-
and Guaranteed-Service with ATM", RFC 2381, August 1998.
[4] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin
"Resource ReSerVation Protocol (RSVP) -- Version 1
Specification", RFC 2205, September 1997.
[5] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[6] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M.,
J. Krawczyk, "A Framework for Integrated Services and RSVP
ATM", RFC 2382, August 1998.
[7] Luciani, J., Katz, D., Piscitello, D., and B. Cole, "NBMA
Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[8] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E.,
A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
February 1995.
Berger Best Current Practice [Page 7]
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Berger Best Current Practice [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
