home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- 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]
-
-