As per Relevance of the word recommendations, we have this rfc below:
Network Working Group M.
Request for Comments: 1754 Com21, Inc
Category: Informational January 1995
IP over ATM Working Group'
Recommendations for the ATM Forum's Multiprotocol
Version 1
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
1.
This document represents an initial list of requirements submitted
the ATM Forum's Multiprotocol BOF for the operation of IP over
networks as determined by the IETF IP over ATM Working Group
other working groups. This RFC is issued for the benefit of
members. The information contained in this document is accurate
of the date of publication, but is subject to change.
RFCs will reflect such changes
The content of this memo was submitted by the IETF Liaison to the
Forum as contribution number 94-0954 in the ATM Forum's
process on 14 September 1994.
2.
This contribution has been prepared to assist the ATM Forum.
document is offered to the Forum as a basis for discussion
the ATM Forum Multiprotocol BOF and the IETF. The statements
subject to change in form and content after further study
discussion. Specifically, the IETF reserves reserves the right
add to, amend or modify the statements contained herein
3.
The following is the charter statement from the Internet
Task Force's (IETF) IP over ATM Working Group (IPATM WG). It
being reproduced here for the benefit of those in the ATM Forum
may not be familiar with it
"The IP over ATM Working Group will focus on the issues involved
running internetworking protocols over Asynchronous Transfer
(ATM) networks. The final goal for the Working Group is to
Laubach [Page 1]
RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
standards for the TCP/IP protocol suite and recommendations
could be used by other internetworking protocol standards (e.g.,
CLNP and IEEE 802.2 Bridging).
The Working Group will initially develop experimental protocols
encapsulation, multicasting, addressing, address resolution, call
up, and network management to allow the operation of
protocols over an ATM network. The Working Group may later
these protocols for IETF standardization
The Working Group will not develop physical layer standards for ATM
These are well covered in other standards groups and do not need
be addressed in this Group
The Working Group will develop models of ATM
architectures. This will be used to guide the development
specific IP over ATM protocols
The Working Group will also develop and maintain a list of
unknowns that relate to internetworking over ATM. These will be
to direct future work of the Working Group or be submitted to
standards or research groups as appropriate
The Working Group will coordinate its work with other
standards bodies (e.g., ANSI T1S1.5) to insure that it does
duplicate their work and that its work meshes well with
activities in this area. The Working Group will select among
protocol options (e.g., selection of an adaptation layer) and
recommendations to the ATM standards bodies regarding
requirements for internetworking over ATM where the current
standards do not meet the needs of internetworking."
Historically, a large number of IETF IPATM WG participants
employees of companies who are principal members of the ATM Forum
Requirements between the two organizations have been
informally by these participants. With the establishment of the
Forum's Multiprotocol BOF activities, it has become prudent now
document IETF requirements in a more formal fashion
At the July 1994 meeting of the IETF in Toronto, Canada, a
was presented to the IP over ATM Working Group by the ATM
Liaison, Drew Perkins, for the working group to prepare a list
requirements as input to the ATM Forum's Multiprotocol
activities. This document is a response to that request
Laubach [Page 2]
RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
4. List of Requirements for
4.1 Standardization &
- Formal communications between the IETF and the ATM
should be made via IETF <> ATM Forum Liaison(s),
written communications (such as this document), and/
presentations made at official IETF or ATM Forum meetings
- IETF standards define how the TCP/IP protocol suite is defined
deployed, and carried over specific network technologies
including ATM networks [1][2][8].
- Any formal communications that affect the IETF
or processes must be made publicly available as the IETF
a public international standards body. Ideally,
communications should be written as Internet Drafts [1],
IETF's equivalent to incoming contributions
- We invite and encourage ATM Forum members to participate
the IETF standards process. See [1], [2], and [8]
information on how to participate
4.2 IPv4
- RFC 1483 [3] and RFC 1577 [4] define how IP is
and carried over ATM networks. The IPATM WG requests that
ATM Forum Multiprotocol work support these standards
specified, and that any future changes to them be made via
IETF standards process
4.3
- RFC 1577 defines the default Logical IP Subnet (LIS) model
- The IETF Routing over Large Clouds Working Group is
the Next Hop Resolution Protocol, which allows the
optimization of routing (and subnets) by routing
over preferential ATM paths [9].
- The IETF IP over ATM Working Group will be working on
next generation IP over ATM standards after RFC 1577
from draft to proposed status. Requirements to the
Forum will be forthcoming
- ATM signaling should give an indication of
over LAN or WAN and include feedback of time vs
charging
Laubach [Page 3]
RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
4.4
- ATM signaling should support a user information
that is used to convey security and authentication
between IP members and applications. The IETF IPATM WG
like to define the IP specific content of this IE
4.5 Broadcast and
- The IPATM WG is currently discussing models of how best to
IP multicast facilities onto ATM facilities. While this work
preliminary, the IETF does support the ATM Forum's
planned multicasting enhancements, such as leaf-initiated
and support of multiple multicast congestion
policies. A further list of requirements will be presented at
later time
4.6 Signaling and
- The IPATM WG is currently producing a specification for
UNI 3.0 and 3.1 signaling to support RFCs 1483 and 1577.
specification will be published as an informational
for UNI 3.0 signaling, and as a proposed standard for UNI 3.1
signaling following UNI 3.1's ratification and
publication
- IPv6 packets will include a Flow ID field intended to
service classes in some way. Until the semantics of this
are fully defined it is hard to say much, but presumably a
mapping between this and the VC to be used is desirable.
further list of requirements will be presented at a later time
- IPv6 addresses will be 16 bytes and there will likely be
defined embedding of them inside 20-byte NSAP format. There
also likely be a mapping of US-GOSIP-like NSAPs into IPv
addresses (deleting the unuseful bytes), but that is
controversial in the IPv6 discussions. A further list
requirements will be presented at a later time
Laubach [Page 4]
RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
4.7 Quality of Service, Performance, and Traffic
- ATM should support extremely bursty applications
significant elasticity in their bandwidth demands
- ATM should support elastic applications as defined
RFC-1633 [7] very efficiently. That means enable
bottleneck utilization while keeping delay reasonably
(i.e., doubling delay wouldn't be terrible for elastic apps).
This should not be at the expense of delay sensitive
of service
- ATM should provide a a class of service which strives
cooperate with existing TCP congestion avoidance,
explicitly providing support not only for directly ATM-
and -aware endstations, but also for endstations on LANs (
using LAN Emulation) that are using current TCP
and interconnected via ATM-attached bridges and routers
- Predictive QoS should be supported in addition to guaranteed
to support applications which are somewhat tolerant of
variation and low levels of loss
- IP uses both point-to-point and point-to-multipoint (future
connections. To satisfy IP's needs an ABR-like
would need to be applicable to both types of connections [6].
- No specification of minimum or maximum bandwidths by the
end-systems [6].
- As simple as possible [6].
- Full line-rate transmission over otherwise-idle links [6].
- When end-to-end delay through the network is less than 1 second
the cell loss for AAL5 frames over an ABR-like service should
on the order of 3 in 10**8 cells for 1500 byte frames, or 3
10**9 cells for 18 Kbyte frames [6].
5. Security
Security issues raised in this memo will be addressed by the IETF
over ATM Working Group and presented in subsequent updates to
memo
Laubach [Page 5]
RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
6.
The basis of this memo is a summary of comments made on the
discussion list of the IP over ATM Working Group. The
was reviewed by Drew Perkins and Andy Malis as a sanity check
submission to the ATM Forum
7.
[1] IETF Secretariat and G. Malkin, "The Tao of the IETF - A
for New Attendees of the Internet Engineering Task Force",
FYI 17, RFC 1718, CNRI, Xylogics, Inc., November 1994.
[2] Internet Architecture Board, and Internet Engineering
Group, "The Internet Standards Process -- Revision 2", RFC 1602,
IAB, IESG, March 1994.
[3] Heinanen, J., "Multiprotocol Encapsulation over ATM
Layer 5", RFC 1483, Telecom Finland, July 1993.
[4] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
Hewlett-Packard Laboratories, January 1994.
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, Stanford University, August 1989.
[6] McCloghrie, K., "Lan-Emulation's Needs for Traffic Management",
ATM-Forum/94-0533, ATM Forum, June 1994.
[7] Braden, R., Clark, D., and S. Shenker, "Integrated
in the Internet Architecture: an Overview", RFC 1633,
USC/Information Sciences Institute, MIT, Xerox PARC, June 1994.
[8] Postel, J., Editor, "Internet Official Protocol Standards",
STD 1, RFC 1720, USC/Information Sciences Institute, July 1994.
[9] Malis, A., "Routing Over Large Clouds Liaison to the ATM
Multiprotocol BOF", ATM-Forum/94-0766, ATM Forum
September 1994.
Laubach [Page 6]
RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
8. IETF <> ATM Forum
Drew
FORE Systems, Inc
174 Thornhill
Warrendale, PA 15086
Phone: (412) 772-6527
Fax: (412) 772-6500
Email: ddp@fore.
9. Author's
Mark
Com21, Inc
2113 Landings
Mountain View, CA 94043
Phone: (415) 254-5882
Fax: (415) 254-5883
EMail: laubach@com21.
Laubach [Page 7]
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
