[ smarcus: RFC 1550 - Requirements for IPng ]

cmills@bbn.com Wed, 19 January 1994 17:06 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05415; 19 Jan 94 12:06 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05407; 19 Jan 94 12:06 EST
Received: from wugate.wustl.edu by CNRI.Reston.VA.US id aa10194; 19 Jan 94 12:06 EST
Received: by wugate.wustl.edu (5.67b+/WUSTL-0.3) with SMTP id AA21214; Wed, 19 Jan 1994 10:57:02 -0600
Message-Id: <199401191657.AA21214@wugate.wustl.edu>
Date: Wed, 19 Jan 1994 11:51:59 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: cmills@bbn.com
X-Orig-Sender: "ONC List Processor V0.2" <listserv@wugate.wustl.edu>
Reply-To: accounting-wg@wugate.wustl.edu
To: accounting-wg@wugate.wustl.edu
Errors-To: accounting-wg-errors@wugate.wustl.edu
Subject: [ smarcus: RFC 1550 - Requirements for IPng ]

Hi Folks,

I just saw this ... is anyone writing on accounting requirements for IP
next generation?

						Cyndi


 - - - - - - - - - - - - - - - Cut Here - - - - - - - - - - - - - - - -
- - -






 Network Working Group                                         S. Bradner
 Request for Comments: 1550                            Harvard University
 Category: Informational                                        A. Mankin
                                                                      NRL
                                                            December 1993


           IP: Next Generation (IPng) White Paper Solicitation

 Status of this Memo

    This memo provides information for the Internet community.  This memo
    does not specify an Internet standard of any kind.  Distribution of
    this memo is unlimited.

 Table of Contents

    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
    2.   Document Review Process  . . . . . . . . . . . . . . . . . . 2
    3.   Document Format Requirement  . . . . . . . . . . . . . . . . 2
    4.   Outline for IPng Requirements and Concerns White Papers  . . 3
    5.   Engineering considerations . . . . . . . . . . . . . . . . . 3
    6.   Security Considerations  . . . . . . . . . . . . . . . . . . 5
    7.   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 5
    Appendix A - Formatting Rules (from RFC 1543) . . . . . . . . . . 6

 1. Introduction

    The IP: next generation (IPng) area in the IETF is soliciting white
    papers on topics related to the IPng requirements and selection
    criteria.

    All interested parties are invited to submit white papers detailing
    any specific requirements that they feel an IPng must fulfill or any
    factors that they feel might sway the IPng selection.  An example of
    the former might be a submission by a representative of a utility
    company detailing the scaling and addressing features which would be
    required to service future inclusion of utility meters on the
    network.  An example of the other case might be a paper outlining the
    potential effect on IPng of some sections of the future network
    connectivity being provided via wireless networks.

    At this time, we are not accepting white papers that evaluate
    specific IPng proposals.  This type of document will be accepted
    after the various proposal documents are deemed to be clear and
    complete.





 Bradner & Mankin                                                [Page 1]
 
 RFC 1550             IPng White Paper Solicitation         December 1993


    All white papers will be reviewed in a process described below.  As a
    result of these reviews, each white paper will receive the focused
    attention of the IPng directorate and the community.  The white
    papers will be used as resource materials by the IPng Area working
    groups, the directorate, the external review board and the area
    directors, during the selection process.

    The deadline for the submission of these white papers is February 1,
    1994, though early submission is encouraged.

    Submit white papers, general or topic questions, and so on, to
    ipng-wp@harvard.edu.

 2. Document Review Process

    All submitted documents will first be reviewed for clarity by members
    of the IPng directorate and the external review board.  This review
    may produce suggestions to the author on areas of the document where
    there may be some confusion as to the meaning.  Authors are urged to
    consider any such suggestions as constructive and to reexamine their
    text in light of the suggestions.

    A separate technical review will then be done of the white paper.
    This review will be conducted within the context of the document.
    That is, the review still will not make value judgments on the white
    papers, but will assess technical feasibility.  This review may also
    produce suggestions to the author.

    The document will be submitted as an Internet-Draft after these
    reviews have been completed and after whatever (if any) revisions
    that the author decides to make.   After a suitable period of time
    these documents will be submitted as informational RFCs unless
    withdrawn by the author.  These documents will comprise a part of the
    historical record of the IPng process.

 3. Document Format Requirements

    All white papers must follow the format requirements listed in RFC
    1543 and must not exceed 10 pages in length. (The relevant portion of
    RFC 1543 is included in this document as Appendix A.)  They should
    not include the "status of memo" section; this will be added when the
    documents are posted as Internet Drafts.  The reference version of
    the document must be in ASCII as is current practice with all RFCs.
    A PostScript version of the document may be submitted in addition to
    the ASCII version. (See RFC 1543 for the formatting procedures to use
    with PostScript documents.)





 Bradner & Mankin                                                [Page 2]
 
 RFC 1550             IPng White Paper Solicitation         December 1993


 4. Outline for IPng Requirements and Concerns White Papers

    This section details the white paper outline to be followed by
    someone who would like to express an opinion about the various
    factors involved in the IPng definition and selection process.  Since
    these documents will be used as resource material by the various IPng
    working groups, the directorate, the external review board and the
    area directors, they should be well-focused and give specific
    references to data supporting their points.

    Each white paper should begin with an executive summary of the
    important points of the document.  This executive summary should not
    exceed 1/2 page in length.

    The white paper should then address the issue or issues that the
    author feels should be understood during the IPng process.  The total
    document should not exceed 10 pages in length.  An author may submit
    more than one white paper if he or she feels that the level of
    detailed discussion on each topic warrants it.

 5. Engineering considerations

    In past discussions the following issues have been raised as relevant
    to the IPng selection process.  This list is in no particular order.
    Any or all of these issues may be addressed as well as any other
    topic that the author feels is germane, but do not exceed the 10 page
    limit, please.

    5.1  Scaling - What is a reasonable estimate for the scale of the
       future data networking environment?  The current common wisdom is
       that IPng should be able to deal with 10 to the 12th nodes.

    5.2  Timescale - What are reasonable time estimates for the IPng
       selection, development and deployment process or what should the
       timeframe requirements be?  This topic is being evaluated by the
       ALE working group and a copy of all white papers that express
       opinions about these topics will be forwarded to that group.

    5.3  Transition and deployment - Transition from the current version
       to IPng will be a complex and difficult process.  What are the
       issues that should be considered The TACIT working group will be
       discussing these issues and a copy of all white papers that
       express opinions about these topics will be forwarded to that
       group.

    5.4  Security - What level and type of security will be required in
       the future network environment?  What features should be in an
       IPng to facilitate security?



 Bradner & Mankin                                                [Page 3]
 
 RFC 1550             IPng White Paper Solicitation         December 1993


    5.5  Configuration, administration and operation - As networks get
       larger and more complex, the day to day operational aspects become
       ever more important.  What should an IPng include or avoid in
       order to minimize the effect on the network operators?

    5.6  Mobile hosts - How important is the proliferation of mobile
       hosts to the IPng selection process?  To what extent should
       features be included in an IPng to assist in dealing with mobile
       hosts?

    5.7  Flows and resource reservation - As the data networks begin to
       get used for an increasing number of time-critical processes, what
       are the requirements or concerns that affect how IPng should
       facilitate the use of resource reservations or flows?

    5.8  Policy based routing - How important is policy based routing?
       If it is important, what types of policies will be used?  What
       requirements do routing policies and potential future global
       architectures of the Internet bring to IPng?  How do policy
       requirements interact with scaling?

    5.9  Topological flexibility - What topology is anticipated for the
       Internet?  Will the current general topology model continue?  Is
       it acceptable (or even necessary) to place significant topological
       restrictions on interconnectivity of networks?

    5.10 Applicability - What environment / marketplace do you see for
       the application of IPng?  How much wider is it than the existing
       IP market?

    5.11 Datagram service - Existing IP service is "best effort" and
       based on hop-by-hop routed datagrams.  What requirements for this
       paradigm influence the IPng selection?

    5.12 Accounting - How important a consideration should the ability to
       do accounting be in the selection of an IPng?  What, if any,
       features should be included in an IPng to support accounting
       functions?

    5.13 Support of communication media - IPv4 can be supported over most
       known types of communications media.  How important is this same
       flexibility to an IPng?









 Bradner & Mankin                                                [Page 4]
 
 RFC 1550             IPng White Paper Solicitation         December 1993


    5.14 Robustness and fault tolerance - To the extent that the Internet
       built from IPv4 has been highly fault tolerant, what are ways that
       IPng may avoid inadvertent decrease in the robustness (since some
       things may work despite flaws that we do not understand well).
       Comment on any other ways in which this requirement may affect the
       IPng.

    5.15 Technology pull - Are there technologies that will pull the
       Internet in a way that should influence IPng?  Can specific
       strategies be developed to encompass these?

    5.16 Action items - suggested charges to the directorate, working
       groups or others to support the concerns or gather more
       information needed for a decision.

 6.  Security Considerations

    This RFC raises no security issues, but does invite comment on the
    security requirements of IPng.

 7.  Authors' Addresses

    Scott Bradner
    Harvard University
    10 Ware St.
    Cambridge, MA 02138

    Phone: (617) 495-3864

    EMail: sob@harvard.edu


    Allison Mankin
    Naval Research Laboratory
    c/o Code 5591
    Washington D.C. 20375-5000

    Phone: 202-404-7030

    EMail: mankin@cmf.nrl.navy.mil











 Bradner & Mankin                                                [Page 5]
 
 RFC 1550             IPng White Paper Solicitation         December 1993


 Appendix  A - Formatting Rules (from RFC 1543)

    Note: there are a set of NROFF formatting macros for the following
    format.  Please contact ipng-wp@harvard.edu if you would like to get
    a copy.

    3a.  ASCII Format Rules

       The character codes are ASCII.

       Each page must be limited to 58 lines followed by a form feed on a
       line by itself.

       Each line must be limited to 72 characters followed by carriage
       return and line feed.

       No overstriking (or underlining) is allowed.

       These "height" and "width" constraints include any headers,
       footers, page numbers, or left side indenting.

       Do not fill the text with extra spaces to provide a straight right
       margin.

       Do not do hyphenation of words at the right margin.

       Do not use footnotes.  If such notes are necessary, put them at
       the end of a section, or at the end of the document.

       Use single spaced text within a paragraph, and one blank line
       between paragraphs.

       Note that the number of pages in a document and the page numbers
       on which various sections fall will likely change with
       reformatting.  Thus cross references in the text by section number
       usually are easier to keep consistent than cross references by
       page number.














 Bradner & Mankin                                                [Page 6]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--------     End of Forwarded Message(s)   ---------