FYI on Questions and Answers: Answers to commonly asked "new internet user" questions
RFC 1177
Document | Type |
RFC
- Informational
(August 1990)
Obsoleted by RFC 1206
|
|
---|---|---|---|
Authors | Joyce K. Reynolds , Gary S. Malkin , April Marine | ||
Last updated | 2013-03-02 | ||
RFC stream | Legacy stream | ||
Formats | |||
IESG | Responsible AD | (None) | |
Send notices to | (None) |
RFC 1177
Network Working Group G. Malkin Request for Comments: 1177 FTP Software, Inc. FYI: 4 A. Marine SRI J. Reynolds ISI August 1990 FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions Status of this Memo This FYI RFC is one of three FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. Distribution of this memo is unlimited. Table of Contents 1. Introduction.................................................... 1 2. Acknowledgements................................................ 2 3. Questions About the Internet.................................... 2 4. Questions About TCP/IP.......................................... 3 5. Questions About Internet Documentation.......................... 4 6. Questions about Internet Organizations and Contacts............. 6 7. Questions About Services........................................ 9 8. Mailing Lists................................................... 11 9. References...................................................... 11 10. Suggested Reading.............................................. 12 11. Condensed Glossary............................................. 12 12. Security Considerations........................................ 23 13. Authors' Addresses............................................. 24 1. Introduction New users joining the Internet community for the first time have had the same questions as did everyone else who has ever joined. Our quest is to provide the Internet community with up to date, basic Internet knowledge and experience, while moving the redundancies away from the electronic mailing lists so that the lists' subscribers do not have to read the same queries and answers over and over again. Future updates of this memo will be produced as USWG members become User Services Working Group [Page 1] RFC 1177 FYI Q/A - for New Internet Users August 1990 aware of additional questions that should be included, and of deficiencies or inaccuracies that should be amended in this document. Additional FYI Q/A's will be published which will deal with intermediate and advanced Q/A topics. The Q/A mailing lists are maintained by Gary Malkin at FTP.COM. They are used by a subgroup of the USWG to discuss the Q/A FYIs. They include: quail@ftp.com This is a discussion mailing list. Its primary use is for pre-release (to the USWG) review of the Q/A FYIs. quail-request@ftp.com This is how you join the quail mailing list. quail-box@ftp.com This is where the questions and answers will be forwarded-and-stored. It is not necessary to be on the quail mailing list to forward to the quail-box. 2. Acknowledgements The following people deserve thanks for their help and contributions to the FYI Q/As: Berlin Moore (PREPNet), Craig Partridge (BBN), Jon Postel (ISI), Karen Roubicek (BBNST), James Van Bokkelen (FTP Software, Inc.), John Wobus (Syracuse University), and David Paul Zimmerman (Rutgers). 3. Questions About the Internet I just got on the Internet. What can I do now? You now have access to all the resources you are authorized to use on your own Internet host, on any other Internet host on which you have an account, and on any other Internet host that offers publicly accessible information. The Internet gives you the ability to move information between these hosts via file transfers. Once you are logged into one host, you can use the Internet to open a connection to another, log in, and use its services interactively. In addition, you can send electronic mail to users at any Internet site and to users on many non-Internet sites that are accessible via electronic mail. There are various other services you can use. For example, some hosts provide access to specialized databases or to archives of information. The Internet Resource Guide provides information regarding some of these sites. The Internet Resource Guide lists facilities on the Internet that are available to users. Such Gundogan, et al. Expires September 10, 2020 [Page 3] Internet-Draft ICN Adaptation to LoWPANs March 2020 bandwidth transmissions, and increased latencies. IEEE 802.15.4 admits a maximum physical layer packet size of 127 octets. The maximum frame header size is 25 octets, which leaves 102 octets for the payload. IEEE 802.15.4 security features further reduce this payload length by up to 21 octets, yielding a net of 81 octets for CCNx or NDN packet headers, signatures and content. 6LoWPAN [RFC4944], [RFC6282] is a convergence layer that provides frame formats, header compression and link fragmentation for IPv6 packets in IEEE 802.15.4 networks. The 6LoWPAN adaptation introduces a dispatching framework that prepends further information to 6LoWPAN packets, including a protocol identifier for IEEE 802.15.4 payload and meta information about link fragmentation. Prevalent Type-Length-Value (TLV) based packet formats such as in CCNx and NDN are designed to be generic and extensible. This leads to header verbosity which is inappropriate in constrained environments of IEEE 802.15.4 links. This document presents ICN LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN. ICN LoWPAN compresses packet headers of CCNx as well as NDN and allows for an increased effective payload size per packet. Additionally, reusing the dispatching framework defined by 6LoWPAN enables compatibility between coexisting wireless networks of competing technologies. This also allows to reuse the link fragmentation scheme specified by 6LoWPAN for ICN LoWPAN. ICN LoWPAN defines a more space efficient representation of CCNx and NDN packet formats. This syntactic change is described for CCNx and NDN separately, as the header formats and TLV encodings differ notably. For further reductions, default header values suitable for constrained IoT networks are selected in order to elide corresponding TLVs. Experimental evaluations of the ICN LoWPAN header compression schemes in [ICNLOWPAN] illustrate a reduced message overhead, a shortened message airtime, and an overall decline in power consumption for typical Class 2 devices compared to uncompressed ICN messages. In a typical IoT scenario (see (Figure 1)), embedded devices are interconnected via a quasi-stationary infrastructure using a border router (BR) that uplinks the constrained LoWPAN network by some Gateway with the public Internet. In ICN based IoT networks, non- local Interest and Data messages transparently travel through the BR up and down between a Gateway and the embedded devices situated in the constrained LoWPAN. Gundogan, et al. Expires September 10, 2020 [Page 4] Internet-Draft ICN Adaptation to LoWPANs March 2020 |Gateway Services| ------------------------- | ,--------, | | | BR | | | '--------' LoWPAN O O O O O embedded O O O devices O O Figure 1: IoT Stub Network The draft has received fruitful reviews by members of the ICN community and the research group (see Acknowledgments) for a period of two years. It is the consensus of ICNRG that this document should be published in the IRTF Stream of the RFC series. This document does not constitute an IETF standard. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed. This document uses the terminology of [RFC7476], [RFC7927], and [RFC7945] for ICN entities. The following terms are used in the document and defined as follows: ICN LoWPAN: Information-Centric Networking over Low-power Wireless Personal Area Network LLN Low-Power and Lossy Network CCNx: Content-Centric Networking Architecture NDN: Named Data Networking Architecture time-value: a time value measured in seconds Gundogan, et al. Expires September 10, 2020 [Page 5] Internet-Draft ICN Adaptation to LoWPANs March 2020 time-code: an 8-bit encoded time-value 3. Overview of ICN LoWPAN 3.1. Link-Layer Convergence ICN LoWPAN provides a convergence layer that maps ICN packets onto constrained link-layer technologies. This includes features such as link-layer fragmentation, protocol separation on the link-layer level, and link-layer address mappings. The stack traversal is visualized in Figure 2. Device 1 Device 2 ,------------------, Router ,------------------, | Application . | __________________ | ,-> Application | |----------------|-| | NDN / CCNx | |-|----------------| | NDN / CCNx | | | ,--------------, | | | NDN / CCNx | |----------------|-| |-|--------------|-| |-|----------------| | ICN LoWPAN | | | | ICN LoWPAN | | | | ICN LoWPAN | |----------------|-| |-|--------------|-| |-|----------------| | Link-Layer | | | | Link-Layer | | | | Link-Layer | '----------------|-' '-|--------------|-' '-|----------------' '--------' '---------' Figure 2: ICN LoWPAN convergence layer for IEEE 802.15.4 Section 4 of this document defines the convergence layer for IEEE 802.15.4. 3.2. Stateless Header Compression ICN LoWPAN also defines a stateless header compression scheme with the main purpose of reducing header overhead of ICN packets. This is of particular importance for link-layers with small MTUs. The stateless compression does not require pre-configuration of global state. The CCNx and NDN header formats are composed of Type-Length-Value (TLV) fields to encode header data. The advantage of TLVs is its native support of variably structured data. The main disadvantage of TLVs is the verbosity that results from storing the type and length of the encoded data. The stateless header compression scheme makes use of compact bit fields to indicate the presence of optional TLVs in the uncompressed packet. The order of set bits in the bit fields corresponds to the order of each TLV in the packet. Further compression is achieved by Gundogan, et al. Expires September 10, 2020 [Page 6] Internet-Draft ICN Adaptation to LoWPANs March 2020 specifying default values and reducing the codomain of certain header fields. Figure 3 demonstrates the stateless header compression idea. In this example, the first type of the first TLV is removed and the corresponding bit in the bit field is set. The second TLV represents a fixed-length TLV (e.g., the Nonce TLV in NDN), so that the type and the length fields are removed. The third TLV represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for which the type, length and the value fields are elided. Uncompressed: Variable-length TLV Fixed-length TLV Boolean TLV ,-----------------------,-----------------------,-------------, +-------+-------+-------+-------+-------+-------+------+------+ | TYP | LEN | VAL | TYP | LEN | VAL | TYP | LEN | +-------+-------+-------+-------+-------+-------+------+------+ Compressed: +---+---+---+---+---+---+---+---+ | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit field +---+---+---+---+---+---+---+---+ | | | ,--' '----, '- Boolean Value | | +-------+-------+-------+ | LEN | VAL | VAL | +-------+-------+-------+ '---------------'-------' Var-len Value Fixed-len Value Figure 3: Compression using a compact bit field - bits encode the inclusion of TLVs. Stateless TLV compression for NDN is defined in Section 5. Section 6 defines the stateless TLV compression for CCNx. The extensibility of this compression is described in Section 4.1.1 and allows future documents to update the compression rules outlined in this manuscript. 3.3. Stateful Header Compression ICN LoWPAN further employs two orthogonal stateful compression schemes for packet size reductions which are defined in Section 8. These mechanisms rely on shared contexts that are either distributed Gundogan, et al. Expires September 10, 2020 [Page 7] Internet-Draft ICN Adaptation to LoWPANs March 2020 and maintained in the entire LoWPAN, or are generated on-demand hop- wise on a particular Interest-data path. The shared context identification is defined in Section 8.1. The hop-wise name compression "en-route" is specified in Section 8.2. 4. IEEE 802.15.4 Adaptation 4.1. LoWPAN Encapsulation The IEEE 802.15.4 frame header does not provide a protocol identifier for its payload. This causes problems of misinterpreting frames when several network layers coexist on the same link. To mitigate errors, 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation headers can prepend the actual payload and each encapsulation header is identified by a dispatch type. [RFC8025] further specifies dispatch pages to switch between different contexts. When a LoWPAN parser encounters a "Page switch" LoWPAN encapsulation header, then all following encapsulation headers are interpreted by using a dispatch table as specified by the "Page switch" header. Page 0 and page 1 are reserved for 6LoWPAN. This document uses page TBD1 ("1111 TBD1 (0xFTBD1)") for NDN and page TBD2 ("1111 TBD2 (0xFTBD2)") for CCNx. The base dispatch format (Figure 4) is used and extended by CCNx and NDN in Section 5 and Section 6. 0 1 2 ... +---+---+----------- | C | M | +---+---+----------- Figure 4: Base dispatch format for ICN LoWPAN C: Compression 0: The message is uncompressed. 1: The message is compressed. M: Message Type 0: The payload contains an Interest message. 1: The payload contains a Data message. Gundogan, et al. Expires September 10, 2020 [Page 8] Internet-Draft ICN Adaptation to LoWPANs March 2020 ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the extended dispatch format in Figure 5. 0 1 2 3 ... +---+---+---+---+--- | 1 | M |CID|EXT| +---+---+---+---+--- Figure 5: Extended dispatch format for compressed ICN LoWPAN CID: Context Identifier 0: No context identifiers are present. 1: Context identifier(s) are present (see Section 8.1). EXT: Extension 0: No extension octets are present. 1: Extension octet(s) are present (see Section 4.1.1). The encapsulation format for ICN LoWPAN is displayed in Figure 6. +------...------+------...-----+--------+-------...-------+-----... | IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. / +------...------+------...-----+--------+-------...-------+-----... Figure 6: LoWPAN Encapsulation with ICN-LoWPAN IEEE 802.15.4: The IEEE 802.15.4 header. RFC4944 Disp.: Optional additional dispatches defined in Section 5.1 of [RFC4944] Page: Page Switch. TBD1 for NDN and TBD2 for CCNx. ICN LoWPAN: Dispatches as defined in Section 5 and Section 6. Payload: The actual (un-)compressed CCNx or NDN message. 4.1.1. Dispatch Extensions Extension octets allow for the extensibility of the initial compression rule set. The base format for an extension octet is depicted in Figure 7. User Services Working Group [Page 2] RFC 1177 FYI Q/A - for New Internet Users August 1990 facilities include supercomputer centers, library catalogs and specialized data collections. The guide is published by the NSF Network Service Center (NNSC) and is continuously being updated. The Resource Guide is distributed free via e-mail (send a note to resource-guide-request@nnsc.nsf.net to join the e-mail distribution) and via anonymous FTP (in nnsc.nsf.net:resource- guide/*). Hardcopy is available at a nominal fee (to cover reproduction costs) from the NNSC. Call the NNSC at 617-873-3400 for more information. How do I find out if a site has a computer on the Internet? Three good sources to consult are "!%@:: A Directory of Electronic Mail Addressing and Networks" by Donnalyn Frey and Rick Adams; "The User's Directory to Computer Networks", by Tracy LaQuey; and "The Matrix: Computer Networks and Conferencing Systems Worldwide", by John Quarterman. In addition, it is possible to find some information about Internet sites in the WHOIS database maintained at the DDN NIC at SRI International. The DDN NIC provides an information retrieval interface to the database that is also called WHOIS. To use this interface, Telnet to NIC.DDN.MIL and type "whois" (carriage return). No login is necessary. Type "help" at the whois prompt for more information on using the facility. WHOIS will show many sites, but may not show every site registered with the DDN NIC (simply for reasons having to do with how the program is set up to search the database). 4. Questions About TCP/IP What is TCP/IP? TCP/IP (Transmission Control Protocol/Internet Protocol) [4,5,6] is the common name for a family of data-communications protocols used to tie computers and data-communications equipment into computer networks. TCP/IP originated for use on a network called ARPANET, but it is currently used on a large international network of universities, other research institutions, government facilities, and some corporations called the Internet. TCP/IP is also sometimes used for other networks, particularly local area networks that tie together numerous different kinds of computers or tie together engineering workstations. What are the other standard protocols in the TCP/IP family? Other than TCP and IP, the three main protocols in the TCP/IP suite are the Simple Mail Transfer Protocol (SMTP), the File User Services Working Group [Page 3] RFC 1177 FYI Q/A - for New Internet Users August 1990 Transfer Protocol (FTP), and the Telnet Protocol. There are many other protocols in use on the Internet. The Internet Activities Board (IAB) regularly publishes an RFC [2] that describes the state of standardization of the various Internet protocols. This document is the best guide to the current status of Internet protocols and their recommended usage. 5. Questions About Internet Documentation What is an RFC? The Request for Comments documents (RFCs) are working notes of the Internet research and development community. A document in this series may be on essentially any topic related to computer communication, and may be anything from a meeting report to the specification of a standard. Submissions for Requests for Comments may be sent to the RFC Editor, Jon Postel (POSTEL@ISI.EDU). Most RFCs are the descriptions of network protocols or services, often giving detailed procedures and formats providing the information necessary for creating implementations. Other RFCs report on the results of policy studies or summarize the work of technical committees or workshops. While RFCs are not refereed publications, they do receive technical review from either the task forces, individual technical experts, or the RFC Editor, as appropriate. Currently, most standards are published as RFCs, but not all RFCs specify standards. Anyone can submit a document for publication as an RFC. Submissions must be made via electronic mail to the RFC Editor. RFCs are distributed online by being stored as public access files, and a short message is sent to the distribution list indicating the availability of the memo. Requests to be added to this distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. The online files are copied by interested people and printed or displayed at their sites on their equipment. (An RFC may also be returned via electronic mail in response to an electronic mail query.) This means that the format of the online files must meet the constraints of a wide variety of printing and display equipment. Once a document is assigned an RFC number and published, that RFC is never revised or re-issued with the same number. There is never a question of having the most recent version of a particular User Services Working Group [Page 4] RFC 1177 FYI Q/A - for New Internet Users August 1990 RFC. However, a protocol (such as File Transfer Protocol (FTP)) may be improved and re-documented many times in several different RFCs. It is important to verify that you have the most recent RFC on a particular protocol. The "IAB Official Protocol Standards" [2] memo is the reference for determining the correct RFC to refer to for the current specification of each protocol. How do I obtain RFCs? RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname RFC:RFCnnnn.TXT or RFC:RFCnnnn.PS (where "nnnn" refers to the number of the RFC). Login with FTP, username "anonymous" and password "guest". The NIC also provides an automatic mail service for those sites which cannot use FTP. Address the request to SERVICE@NIC.DDN.MIL and in the subject field of the message indicate the RFC number, as in "Subject: RFC nnnn" (or "Subject: RFC nnnn.PS" for PostScript RFCs). RFCs can also be obtained via FTP from NIS.NSF.NET. Using FTP, login with username "anonymous" and password "guest"; then connect to the RFC directory ("cd RFC"). The file name is of the form RFCnnnn.TXT-1 (where "nnnn" refers to the number of the RFC). The NIS also provides an automatic mail service for those sites which cannot use FTP. Address the request to NIS-INFO@NIS.NSF.NET and leave the subject field of the message blank. The first line of the text of the message must be "SEND RFCnnnn.TXT-1", where nnnn is replaced by the RFC number. Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC@NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Which RFCs are Standards? See "IAB Official Protocol Standards" (currently, RFC 1140) [2]. How do I obtain OSI Standards documents from the Internet? OSI Standards documents are NOT available from the Internet via anonymous FTP due to copyright restrictions. These are available from: Omnicom Information Service 501 Church Street NE Suite 304 Vienna, VA 22180 USA Telephone: (800) 666-4266 or (703) 281-1135 Fax: (703) 281-1505 User Services Working Group [Page 5] RFC 1177 FYI Q/A - for New Internet Users August 1990 6. Questions about Internet Organizations and Contacts What is the IAB? The Internet Activities Board (IAB) is the coordinating committee for Internet design, engineering and management [7]. IAB members are deeply committed to making the Internet function effectively and evolve to meet a large scale, high speed future. The chairman serves a term of two years and is elected by the members of the IAB. The current Chair of the IAB is Vint Cerf. The IAB focuses on the TCP/IP protocol suite, and extensions to the Internet system to support multiple protocol suites. The IAB performs the following functions: 1) Sets Internet Standards, 2) Manages the RFC publication process, 3) Reviews the operation of the IETF and IRTF, 4) Performs strategic planning for the Internet, identifying long-range problems and opportunities, 5) Acts as an international technical policy liaison and representative for the Internet community, and 6) Resolves technical issues which cannot be treated within the IETF or IRTF frameworks. The IAB has two principal subsidiary task forces: 1) Internet Engineering Task Force (IETF) 2) Internet Research Task Force (IRTF) Each of these Task Forces is led by a chairman and guided by a Steering Group which reports to the IAB through its chairman. For the most part, a collection of Research or Working Groups carries out the work program of each Task Force. All decisions of the IAB are made public. The principal vehicle by which IAB decisions are propagated to the parties interested in the Internet and its TCP/IP protocol suite is the Request for Comments (RFC) note series and the Internet Monthly Report. User Services Working Group [Page 6] RFC 1177 FYI Q/A - for New Internet Users August 1990 What is the IANA? The task of coordinating the use of the parameters of protocols is delegated by the Internet Activities Board (IAB) to the Internet Assigned Numbers Authority (IANA). These protocol parameters are op-codes, type fields, terminal types, system names, object identifiers, and so on. The "Assigned Numbers&Gundogan, et al. Expires September 10, 2020 [Page 9] Internet-Draft ICN Adaptation to LoWPANs March 2020 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | - | - | - | - | - | - | - |EXT| +---+---+---+---+---+---+---+---+ Figure 7: Base format for dispatch extensions. EXT: Extension 0: No other extension octet follows. 1: A further extension octet follows. Extension octets are numbered according to their order. Future documents MUST follow the naming scheme "EXT_0, EXT_1, ...", when updating or referring to a specific dispatch extension octet. Amendments that require an exchange of configurational parameters between devices SHOULD use manifests to encode structured data in a well-defined format, as, e.g., outlined in [I-D.irtf-icnrg-flic]. 4.2. Link Fragmentation Small payload sizes in the LoWPAN require fragmentation for various network layers. Therefore, Section 5.3 of [RFC4944] defines a protocol-independent fragmentation dispatch type, a fragmentation header for the first fragment, and a separate fragmentation header for subsequent fragments. ICN LoWPAN adopts this fragmentation handling of [RFC4944]. The Fragmentation LoWPAN header can encapsulate other dispatch headers. The order of dispatch types is defined in Section 5 of [RFC4944]. Figure 8 shows the fragmentation scheme. The reassembled ICN LoWPAN frame does not contain any fragmentation headers and is depicted in Figure 9. Gundogan, et al. Expires September 10, 2020 [Page 10] Internet-Draft ICN Adaptation to LoWPANs March 2020 +------...------+----...----+--------+------...-------+--------... | IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload / +------...------+----...----+--------+------...-------+--------... +------...------+----...----+--------... | IEEE 802.15.4 | Frag. 2nd | Payload / +------...------+----...----+--------... . . . +------...------+----...----+--------... | IEEE 802.15.4 | Frag. Nth | Payload / +------...------+----...----+--------... Figure 8: Fragmentation scheme +------...------+--------+------...-------+--------... | IEEE 802.15.4 | Page | ICN LoWPAN | Payload / +------...------+--------+------...-------+--------... Figure 9: Reassembled ICN LoWPAN frame 5. Space-efficient Message Encoding for NDN 5.1. TLV Encoding The NDN packet format consists of TLV fields using the TLV encoding that is described in [NDN-PACKET-SPEC]. Type and length fields are of variable size, where numbers greater than 252 are encoded using multiple octets. If the type or length number is less than "253", then that number is encoded into the actual type or length field. If the number is greater or equals "253" and fits into 2 octets, then the type or length field is set to "253" and the number is encoded in the next following 2 octets in network byte order, i.e., from the most significant byte (MSB) to the least significant byte (LSB). If the number is greater than 2 octets and fits into 4 octets, then the type or length field is set to "254" and the number is encoded in the subsequent 4 octets in network byte order. For larger numbers, the type or length field is set to "255" and the number is encoded in the subsequent 8 octets in network byte order. In this specification, compressed NDN TLVs make use of a different TLV encoding scheme that reduces size. Instead of using the first octet as a marker for the number of following octets, the compressed Gundogan, et al. Expires September 10, 2020 [Page 11] Internet-Draft ICN Adaptation to LoWPANs March 2020 NDN TLV scheme uses a method to chain a variable number of octets together. If an octet equals "255 (0xFF)", then the following octet will also be interpreted. The actual value of a chain equals the sum of all constituents. If the type or length number is less than "255", then that number is encoded into the actual type or length field (Figure 10 a). If the type or length number (X) fits into 2 octets, then the first octet is set to "255" and the subsequent octet equals "X mod 255" (Figure 10 b). Following this scheme, a variable-sized number (X) is encoded using multiple octets of "255" with a trailing octet containing "X mod 255" (Figure 10 c). 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ a) | < 255 (X) | = X +-+-+-+-+-+-+-+-+ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ b) | 255 | < 255 (X) | = 255 + X +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ c) | 255 | 255 | < 255 (X) | = (N * 255) + X +-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+ (N) Figure 10: Compressed NDN TLV encoding scheme 5.2. Name TLV Compression This Name TLV compression encodes length fields of two consecutive NameComponent TLVs into one octet, using 4 bits each. This process limits the length of a NameComponent TLV to 15 octets. A length of 0 marks the end of the compressed Name TLV. An example for this encoding is presented in Figure 11. Gundogan, et al. Expires September 10, 2020 [Page 12] Internet-Draft ICN Adaptation to LoWPANs March 2020 Name: /HAW/Room/481/Humid/99 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1|0 1 0 0| H | A | W | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | o | o | m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1|0 1 0 1| 4 | 8 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H | u | m | i | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d |0 0 1 0|0 0 0 0| 9 | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Name TLV compression for /HAW/Room/481/Humid/99 5.3. Interest Messages 5.3.1. Uncompressed Interest Messages An uncompressed Interest message uses the base dispatch format (see Figure 4) and sets the C as well as the M flag to "0" (Figure 12). "resv" MUST be set to 0. The Interest message is handed to the NDN network stack without modifications. 0 1 ... 7 +---+---+-----------------------+ | 0 | 0 | resv | +---+---+-----------------------+ Figure 12: Dispatch format for uncompressed NDN Interest messages 5.3.2. Compressed Interest Messages The compressed Interest message uses the extended dispatch format (Figure 5) and sets the C flag to "1" and the M flag to "0" Request for Comments (RFC) [1] documents the currently assigned values from several series of numbers used in network protocol implementations. Current types of assignments listed in Assigned Numbers and maintained by the IANA are: Address Resolution Protocol Parameters ARPANET and MILNET X.25 Address Mappings ARPANET and MILNET Logical Addresses ARPANET and MILNET Link Numbers BOOTP Parameters and BOOTP Extension Codes Domain System Parameters IANA Ethernet Address Blocks Ethernet Numbers of Interest IEEE 802 Numbers of Interest Internet Protocol Numbers Internet Version Numbers IP Time to Live Parameter IP TOS Parameters Machine Names Mail Encryption Types Multicast Addresses Network Management Parameters PRONET 80 Type Numbers Port Assignments Protocol and Service Names Protocol/Type Field Assignments Public Data Network Numbers Reverse Address Resolution Protocol Operation Codes Telnet Options Terminal Type Names Unix Ports X.25 Type Numbers For more information on number assignments, contact IANA@ISI.EDU. What is "The NIC"? "The NIC" is the Defense Data Network, Network Information Center (DDN NIC) at SRI International, which is a network information User Services Working Group [Page 7] RFC 1177 FYI Q/A - for New Internet Users August 1990 center which holds a primary repository for RFCs and Internet drafts. The host name is NIC.DDN.MIL. Shadow copies of the RFCs and the Internet Drafts are maintained by the NSFnet on NNSC.NSF.NET and on MERIT.EDU. The DDN NIC also provides various user assistance services for DDN users; contact NIC@NIC.DDN.MIL or call 1-800-235-3155 for more information. In addition, the DDN NIC is the Internet registration authority for the root domain and several top and second level domains; maintains the official DoD Internet Host Table; is the site of the Internet Registry (IR); and maintains the whois database of network users, hosts, domains, networks, and Points of Contact. What is the IR? The Internet Registry (IR) is the organization that is responsible for assigning identifiers, such as IP network numbers and autonomous system numbers, to networks. The IR also gathers and registers such assigned information. The IR may, in the future, allocate the authority to assign network identifiers to other organizations; however, it will continue to gather data regarding such assignments. At present, the DDN NIC at SRI International serves as the IR. What is the IETF? The Internet has grown to encompass a large number of widely geographically dispersed networks in academic and research communities. It now provides an infrastructure for a broad community with various interests. Moreover, the family of Internet protocols and system components has moved from experimental to commercial development. To help coordinate the operation, management and evolution of the Internet, the IAB established the Internet Engineering Task Force (IETF). The IETF is chaired by Phill Gross and managed by its Internet Engineering Steering Group (IESG). The IETF is a large open community of network designers, operators, vendors, and researchers concerned with the Internet and the Internet protocol suite. It is organized around a set of eight technical areas, each managed by a technical area director. In addition to the IETF Chairman, the area directors make up the IESG membership. The IAB has delegated to the IESG the general responsibility for making the Internet work and for the resolution of all short- and mid-range protocol and architectural issues required to make the Internet function effectively. User Services Working Group [Page 8] RFC 1177 FYI Q/A - for New Internet Users August 1990 What is the IRTF? To promote research in networking and the development of new technology, the IAB established the Internet Research Task Force (IRTF). In the area of network protocols, the distinction between research and engineering is not always clear, so there will sometimes be overlap between activities of the IETF and the IRTF. There is, in fact, considerable overlap in membership between the two groups. This overlap is regarded as vital for cross-fertilization and technology transfer. The IRTF is a community of network researchers, generally with an Internet focus. The work of the IRTF is governed by its Internet Research Steering Group (IRSG). The chairman of the IRTF and IRSG is David Clark. 7. Questions About Services How do I find someone's electronic mail address? There are a number of directories on the Internet; however, all of them are far from complete. The two largest directories are the WHOIS database at the DDN NIC and the PSInet White Pages. Generally, it is still necessary to ask the person for his or her email address. How do I use the WHOIS program at the DDN NIC? To use the WHOIS program to search the WHOIS database at the DDN NIC, telnet to the NIC host, NIC.DDN.MIL. There is no need to login. Type "whois" to call up the information retrieval program. Next, type the name of the person, host, domain, network, or mailbox for which you need information. If you are only typing part of the name, end your search string with a period. Type "help" for a more in-depth explanation of what you can search for and how you can search. If you have trouble, send a message to NIC@NIC.DDN.MIL or call 1-800-235-3155. Bug reports can be sent to BUG-WHOIS@NIC.DDN.MIL and suggestions for improvements to the program can be sent to SUGGESTIONS@NIC.DDN.MIL. How do I become registered in the DDN NIC's WHOIS database? If you would like to be listed in the WHOIS database, you must have an electronic mailbox accessible from the Internet. First obtain the file NETINFO:USER-TEMPLATE.TXT. You can either retrieve this file via anonymous FTP from NIC.DDN.MIL or get it User Services Working Group [Page 9] RFC 1177 FYI Q/A - for New Internet Users August 1990 through electronic mail. To obtain the file via electronic mail, send a message to SERVICE@NIC.DDN.MIL and put the file name in the subject line of the message; that is, "Subject: NETINFO USER- TEMPLATE.TXT". The file will be returned to you overnight. Fill out the name and address information requested in the file and return it to REGISTRAR@NIC.DDN.MIL. Your application will be processed and you will be added to the database. Unless you are an official Point of Contact for a network entity registered at the DDN NIC, the DDN NIC will not regularly poll you for updates, so you should remember to send corrections to your information as your contact data changes. How do I use the White Pages at PSI? Performance Systems International, Inc. (PSI), sponsors a White Pages Pilot Project that collects personnel information from member organizations into a database and provides online access to that data. This effort is based on the OSI X.500 Directory standard. To access the data, telnet to WP.PSI.COM and login as "fred" (no password is necessary). You may now look up information on participating organizations. The program provides help on usage. For example, typing "help" will show you a list of commands, quot;. If an Interest message contains TLVs that are not mentioned in the following compression rules, then this message MUST be sent uncompressed. This specification assumes that a HopLimit TLV is part of the original Interest message. If such HopLimit TLV is not present, it will be set with a default value of DEFAULT_NDN_HOPLIMIT prior to the compression. Gundogan, et al. Expires September 10, 2020 [Page 13] Internet-Draft ICN Adaptation to LoWPANs March 2020 In the default use case, the Interest message is compressed with the following minimal rule set: 1. The "Type" field of the outermost MessageType TLV is removed. 2. The Name TLV is compressed according to Section 5.2. For this, all NameComponents are expected to be of type GenericNameComponent with a length greater than 0. An ImplicitSha256DigestComponent or ParametersSha256DigestComponent MAY appear at the end of the name. In any other case, the message MUST be sent uncompressed. 3. InterestLifetime TLV is moved to the end of the compressed Interest and is encoded as described in Section 7. If a lifetime is not a valid time-value, then the lifetime is rounded up to the nearest valid time-value as specified in Section 7. 4. The Type and Length fields of Nonce TLV, HopLimit TLV and InterestLifetime TLV are elided. The Nonce value has a length of 4 octets and the HopLimit value has a length of 1 octet. The compressed InterestLifetime (Section 7) has a length of 1 octet. The presence of an InterestLifetime TLV is deduced from the remaining length to parse. The compressed NDN LoWPAN Interest message is visualized in Figure 13. Gundogan, et al. Expires September 10, 2020 [Page 14] Internet-Draft ICN Adaptation to LoWPANs March 2020 T = Type, L = Length, V = Value, Vc = Compressed Value +---------+---------+ +---------+ | Msg T | Msg L | | Msg L | +---------+---------+---------+ +---------+ | Name T | Name L | Name V | | Name Vc | +---------+---------+---------+ +---------+---------+ | CBPfx T | CBPfx L | | FWDH L | FWDH Vc | +---------+---------+ +---------+---------+ | MBFr T | MBFr L | | NONC V | +---------+---------+---------+ ==> +---------+ | FWDH T | FWDH L | FWDH V | | HPL V | +---------+---------+---------+ +---------+---------+ | NONC T | NONC L | NONC V | | APM L | APM Vc | +---------+---------+---------+ +---------+---------+ | ILT T | ILT L | ILT V | | ILT Vc | +---------+---------+---------+ +---------+ | HPL T | HPL L | HPL V | +---------+---------+---------+ | APM T | APM L | APM V | +---------+---------+---------+ Figure 13: Compression of NDN LoWPAN Interest Message Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 14. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 0 |CID|EXT|PFX|FRE|FWD|APM| +---+---+---+---+---+---+---+---+ Figure 14: Dispatch format for compressed NDN Interest messages CID: Context Identifier See Figure 5. EXT: Extension 0: No extension octet follows. 1: Extension octet "EXT_0" follows immediately. See Section 5.3.3. PFX: CanBePrefix TLV 0: The uncompressed message does not include a CanBePrefix TLV. Gundogan, et al. Expires September 10, 2020 [Page 15] Internet-Draft ICN Adaptation to LoWPANs March 2020 1: The uncompressed message does include a CanBePrefix TLV and is removed from the compressed message. FRE: MustBeFresh TLV 0: The uncompressed message does not include a MustBeFresh TLV. 1: The uncompressed message does include a MustBeFresh TLV and is removed from the compressed message. FWD: ForwardingHint TLV 0: The uncompressed message does not include a ForwardingHint TLV. 1: The uncompressed message does include a ForwardingHint TLV. The Type field is removed from the compressed message. Further, all link delegation types and link preference types are removed. All included names are compressed according to Section 5.2. If any name is not compressible, the message MUST be sent uncompressed. APM: ApplicationParameters TLV 0: The uncompressed message does not include an ApplicationParameters TLV. 1: The uncompressed message does include an ApplicationParameters TLV. The Type field is removed from the compressed message. 5.3.3. Dispatch Extension The "EXT_0" octet follows the description in Section 4.1.1 and is illustrated in Figure 15. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS |DIG| RSV |EXT| +---+---+---+---+---+---+---+---+ Figure 15: EXT_0 format NCS: Name Compression Strategy Gundogan, et al. Expires September 10, 2020 [Page 16] Internet-Draft ICN Adaptation to LoWPANs March 2020 00: Names are compressed with the default name compression strategy (see Section 5.2). 01: Reserved. 10: Reserved. 11: Reserved. DIG: ImplicitSha256DigestComponent TLV 0: The name does not include an ImplicitSha256DigestComponent as the last TLV. If "EXT_0" is absent, then DIG is treated as 0. 1: The name does include an ImplicitSha256DigestComponent as the last TLV. The Type and Length fields are omitted. RSV: Reserved Must be set to 0. EXT: Extension 0: No extension octet follows. 1: A further extension octet follows immediately. 5.4. Data Messages 5.4.1. Uncompressed Data Messages An uncompressed Data message uses the base dispatch format and sets the C flag to "0" and the M flag to "1" (Figure 16). "resv" MUST be set to 0. The Data message is handed to the NDN network stack without modifications. 0 1 ... 7 +---+---+-----------------------+ | 0 | 1 | resv | +---+---+-----------------------+ Figure 16: Dispatch format for uncompressed NDN Data messages 5.4.2. Compressed Data Messages The compressed Data message uses the extended dispatch format (Figure 5) and sets the C flag as well as the M flag to "1". If a Gundogan, et al. Expires September 10, 2020 [Page 17] Internet-Draft ICN Adaptation to LoWPANs March 2020 Data message contains TLVs that are not mentioned in the following compression rules, then this message MUST be sent uncompressed. By default, the Data message is compressed with the following base rule set: 1. The "Type" field of the outermost MessageType TLV is removed. 2. The Name TLV is compressed according to Section 5.2. For this, all NameComponents are expected to be of type GenericNameComponent and to have a length greater than 0. In any other case, the message MUST be sent uncompressed. 3. The MetaInfo TLV Type and Length fields are elided from the compressed Data message. 4. The FreshnessPeriod TLV MUST be moved to the end of the compressed Data message and the length is set to 1. Type and Length fields are elided and the value is encoded as described in Section 7. If the freshness period is not a valid time-value, then the message MUST be sent uncompressed in order to preserve the security envelope of the Data message. The presence of a FreshnessPeriod TLV is deduced from the remaining length to parse. 5. The Type fields of the SignatureInfo TLV, SignatureType TLV and SignatureValue TLV are removed. The compressed NDN LoWPAN Data message is visualized in Figure 17. Gundogan, et al. Expires September 10, 2020 [Page 18] Internet-Draft ICN Adaptation to LoWPANs March 2020 T = Type, L = Length, V = Value, Vc = Compressed Value +---------+---------+ +---------+ | Msg T | Msg L | | Msg L | +---------+---------+---------+ +---------+ | Name T | Name L | Name V | | Name Vc | +---------+---------+---------+ +---------+---------+ | Meta T | Meta L | | CTyp L | CType V | +---------+---------+---------+ +---------+---------+ | CTyp T | CTyp L | CTyp V | | FBID V | +---------+---------+---------+ ==&"manual" will give detailed documentation, and "whois" will provide information regarding how to find references to people. For a list of the organizations that are participating in the pilot project by providing information regarding their members, type "whois -org *". For more information, send a message to INFO@PSI.COM. What is Usenet? What is Netnews? Usenet and Netnews are common names of a distributed computer bulletin board system that some computers on the Internet participate in. It is not strictly an Internet service: many computers not on the Internet also participate. How do I get on Usenet? How do I get Netnews on my computer? To get on Usenet, you must acquire the software, which is available for some computers at no cost from some anonymous ftp sites across the Internet, and you must find an existing Usenet site that is willing to support a connection to your computer. User Services Working Group [Page 10] RFC 1177 FYI Q/A - for New Internet Users August 1990 What is anonymous FTP? Anonymous FTP is a conventional way of allowing you to sign on to a computer on the Internet and copy specified public files from it [3]. Some sites offer anonymous FTP to distribute software and various kinds of information. You use it like any FTP, but the username is "anonymous" and the password is "guest". 8. Mailing Lists What are some good mailing lists or news groups? The TCP-IP, IETF, and RFC Distribution lists are primary lists for new Internet users who desire further information about current and emerging developments in the Internet. The first two lists are unmoderated discussion lists, and the latter is an announcement service used by the RFC Editor. How do I subscribe to the TCP-IP mailing list? To be added to the TCP-IP mailing list, send a message to: TCP-IP-REQUEST@NIC.DDN.MIL How do I subscribe to the IETF mailing list? To be added to the IETF mailing list, send a message to: IETF-REQUEST@ISI.EDU How do I subscribe to the RFC Distribution list? To be added to the RFC Distribution list, send a message to: RFC-REQUEST@NIC.DDN.MIL 9. References [1] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990. [2] Postel, J., Editor, "IAB Official Protocol Standards", RFC 1140, Internet Activities Board, May 1990. [3] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP), RFC 959, USC/Information Sciences Institute, October 1985. [4] Postel, J., "Internet Protocol - DARPA Internet Program Protocol User Services Working Group [Page 11] RFC 1177 FYI Q/A - for New Internet Users August 1990 Specification", RFC 791, DARPA, September 1981. [5] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [6] Leiner, B., R. Cole, J. Postel, and D. Mills, "The DARPA Internet Protocol Suite", IEEE INFOCOM85, Washington D.C., March 1985. Also in IEEE Communications Magazine, March 1985. Also as ISI/RS-85-153. [7] Cerf, V., "The Internet Activities Board" RFC 1160, CNRI, May 1990. 10. Suggested Reading For further information about the Internet and its protocols in general, you may choose to obtain copies of the following works: Bowers, K., T. LaQuey, J. Reynolds, K. Roubicek, M. Stahl, and A. Yuan, "Where to Start - A Bibliography of General Internetworking Information", RFC 1175, FYI 3, CNRI, U Texas, ISI, BBN, SRI, Mitre, August 1990. Comer, D., "Internetworking with TCP/IP: Principles, Protocols, and Architecture", Prentice Hall, New Jersey, 1989. Krol, E., "The Hitchhikers Guide to the Internet", RFC 1118, University of Illinois Urbana, September 1989. 11. Condensed Glossary As with any profession, computers have a particular terminology all their own. Below is a condensed glossary to assist in making some sense of the Internet world. address There are two separate uses of this term in internet networking: "electronic mail address" and "internet address". An electronic mail address is the string of characters that you must give an electronic mail program to direct a message to a particular person. See "internet address" for its definition. AI Artificial Intelligence The branch of computer science which deals with the simulation of human intelligence by computer systems. AIX Advanced Interactive Executive IBM's version of Unix. User Services Working Group [Page 12] RFC 1177 FYI Q/A - for New Internet Users August 1990 ANSI American National Standards Institute A group that defines U.S. standards for the information processing industry. ANSI participates in defining network protocol standards. ARP Address Resolution Protocol An Internet protocol which runs on Ethernets and Token Rings which maps internet addresses to MAC addresses. ARPA Advanced Research Projects Agency The former name of what is now called DARPA. ARPANET Advanced Research Projects Agency Network A pioneering long haul network funded by ARPA. It served as the basis for early networking research as well as a central backbone during the development of the Internet. The ARPANET consisted of individual packet switching computers interconnected by leased lines. ASCII American Standard Code for Information Interchange B Byte One character of information, usually eight bits wide. b bit - binary digit The smallest amount of information which may be stored in a computer. BBN Bolt, Beranek, and Newman, Inc. The Cambridge, MA company responsible for development, operation and monitoring of the ARPANET, and later, the Internet core gateway system, the CSNET Coordination and Information Center (CIC), and NSFnet Network Service Center (NNSC). BITNET Because It's Time Network BITNET has about 2,500 host computers, primarily at universities, in many countries. It is managed by EDUCOM, which provides administrative support and information services. There are three main constituents of the network: BITNET in the United States and Mexico, NETNORTH in Canada, and EARN in Europe. There are also AsiaNet, in Japan, and connections in South America. See CREN. bps bits per second A measure of data transmission speed. User Services Working Group [Page 13] RFC 1177 FYI Q/A - for New Internet Users August 1990 BSD Berkeley Software Distribution Term used when describing different versions of the Berkeley UNIX software, as in "4.3BSD UNIX". catenet A network in which hosts are connected to networks with varying characteristics, and the networks are interconnected by gateways (routers). The Internet is an example of a catenet. CCITT International Consultative Committee for Telegraphy and Telephony. core gateway Historically, one of a set of gateways (routers) operated by the Internet Network Operations Center at BBN. The core gateway system forms a central part of Internet routing in that all groups must advertise paths to their networks from a core gateway. CREN The Corporation for Research and Educational Networking BITNET and CSNET have recently merged to form CREN. CSNET Computer + Science Network A large data communications network for institutions doing research in computer science. It uses several different protocols including some of its own. CSNET sites include universities, research laboratories, and commercial companies. See CREN. DARPA U.S. Department of Defense Advanced Research Projects Agency The government agency that funded the ARPANET and later started the Internet. datagram The unit transmitted between a pair of internet modules. The Internet Protocol provides for transmitting blocks of data, called datagrams, from sources to destinations. The Internet Protocol does not provide a reliable communication facility. There are no acknowledgements either end-to-end or hop-by-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is no flow control. See IP. DCA Defense Communications Agency The government agency responsible for installation of User Services Working Group [Page 14] RFC 1177 FYI Q/A - for New Internet Users August 1990 the Defense Data Network (DDN), including the ARPANET and MILNET lines and PSNs. Currently, DCA administers the DDN, and supports the user assistance and network registration services of the DDN NIC. DDN Defense Data Network Comprises the MILNET and several other DoD networks. DDN NIC The network information center at SRI International. It is the primary repository for RFCs and Internet drafts, as well as providing other services. DEC Digital Equipment Corporation DECnet Digital Equipment Corporation network A networking protocol for DEC computers and network devices. default route A routing table entry which is used to direct any data addressed to any network numbers not explicitly listed in the routing table. DOD U.S. Department of Defense DOE U.S. Department of Energy DNS The Domain Name System is a mechanism used in the Internet for translating names of host computers into addresses. The DNS also allows host computers not directly on the Internet to have registered names in the same style. EARN European Academic Research Network One of three main constituents of BITNET. EBCDIC Extended Binary-coded Decimal Interchange Code EGP External Gateway Protocol A protocol which distributes routing information to the routers and gateways which interconnect networks. Ethernet A network standard for the hardware and data link levels. There are two types of Ethernet: Digital/Intel/Xerox (DIX) and IEEE 802.3. User Services Working Group [Page 15] RFC 1177 FYI Q/A - for New Internet Users August 1990 FIPS Federal Information Processing Standard FTP File Transfer Protocol The Internet standard high-level protocol for transferring files from one computer to another. gateway A special-purpose dedicated computer that attaches to two or more networks and routes packets from one network to the other. In particular, an Internet gateway routes IP datagrams among the networks it connects. Gateways route packets to other gateways until they can be delivered to the final destination directly across one physical network. GB Gigabyte A unit of data storage size which represents 2^30 (over 1 billion) characters of information. Gb Gigabit 2^30 bits of information (usually used to express a data transfer rate; as in, 1 gigabit/second = 1Gbps). GNU Gnu's Not UNIX A UNIX-compatible operating system developed by the Free Software Foundation. header The portion of a packet, preceding the actual data, containing source and destination addresses and error-checking fields. host number The part of an internet address that designates which node on the (sub)network is being addressed. HP Hewlett-Packard HYPERchannel High-speed communications link. I/O Input/Output IAB Internet Activities Board The IAB is the coordinating committee for Internet design, engineering and management. User Services Working Group [Page 16] RFC 1177 FYI Q/A - for New Internet Users August 1990 IBM International Business Machines Corporation IEEE Institute for Electrical and Electronics Engineers IETF Internet Engineering Task Force The IETF is a large open community of network designers, operators, vendors, and researchers whose purpose is to coordinate the operation, management and evolution of the Internet, and to resolve short- and mid-range protocol and architectural issues. It is a major source of proposed protocol standards which are submitted to the Internet Activities Board for final approval. The IETF meets three times a year and extensive minutes of the plenary proceedings are issued. internet internetwork Any connection of two or more local or wide-area networks. Internet The global collection of interconnected regional and wide-area networks which use IP as the network layer protocol. internet address An assigned number which identifies a host in an internet. It has two or three parts: network number, optional subnet number, and host number. IP Internet Protocol The network layer protocol for the Internet. It the datagram protocol defined by RFC 791. IRTF Internet Research Task Force The IRTF is a community of network researchers, generally with an Internet focus. The work of the IRTF is governed by its Internet Research Steering Group (IRSG). ISO International Standards Organization JvNC John von Neumann National Supercomputer Center KB Kilobyte A unit of data storage size which represents 2^10 (1024) characters of information. User Services Working Group [Page 17] RFC 1177 FYI Q/A - for New Internet Users August 1990 Kb Kilobit 2^10 bits of information (usually used to express a data transfer rate; as in, 1 kilobit/second = 1Kbps = 1Kb). KNET Kangaroo Network Hardware/software product (Spartacus/Fibronics) that enables IBM mainframes to communicate over networks with the TCP/IP protocol suite. LAN Local Area Network A network that takes advantage of the proximity of computers to offer relatively efficient, higher speed communications than long-haul or wide-area networks. LISP List Processing Language MAC Medium Access Control For broadcast networks, it is the method which devices use to determine which device has line access at any given time. Mac Apple Macintosh computer. MB Megabyte A unit of data storage size which represents over 2^20 (one million) characters of information. Mb Megabit 2^20 bits of information (usually used to express a data transfer rate; as in, 1 megabit/second = 1Mbps). MILNET Military Network A network used for unclassified military production applications. It is part of the Internet. MIT Massachusetts Institute of Technology MTTF Mean Time to Failure The average time between hardware breakdown or loss of service. This may be an empirical measurement or a calculation based on the MTTF of component parts. MTTR Mean Time to Recovery The average time it takes to restore service after a breakdown or loss. This is usually an empirical measurement. User Services Working Group [Page 18] RFC 1177 FYI Q/A - for New Internet Users August 1990 MVS Multiple Virtual Storage An IBM operating system based on OS/1. NASA National Aeronautics and Space Administration NBS National Bureau of Standards Now called NIST. network number The part of an internet address which designates the network to which the addressed node belongs. NFS Network File System A network service that lets a program running on one computer to use data stored on a different computer on the same internet as if it were on its own disk. NIC Network Information Center An organization which provides network users with information about services provided by the network. NOC Network Operations Center An organization which is responsible for maintaining a network. NIST National Institute of Standards and Technology Formerly NBS. NSF National Science Foundation NSFNET National Science Foundation Network A high-speed internet that spans the country, and is intended for research applications. It is made up of the NSFnet Backbone and the NSFnet regional networks. It is part of the Internet. NSFNET Backbone A network connecting 13 sites across the continental United States. It is the central component of NSFnet. NSFNET Regional A network connected to the NSFnet Backbone that covers a region of the United States. It is to the regionals that local sites connect. User Services Working Group [Page 19] RFC 1177 FYI Q/A - for New Internet Users August 1990 NYSERnet New York State Educational and Research Network An internet which serves NY educational and research institutions. It also serves as the NSFnet regional network for New York State. OSI Open Systems Interconnection A set of protocols designed to be an international standard method for connecting unlike computers and networks. Europe has done most of the work developing OSI and will probably use it as soon as possible. OSI Reference Model An "outlinegt; +---------+---------+ | FrPr T | FrPr L | FrPr V | | CONT L | CONT V | +---------+---------+---------+ +---------+---------+ | FBID T | FBID L | FBID V | | Sig L | +---------+---------+---------+ +---------+---------+ | CONT T | CONT L | CONT V | | SInf L | SInf Vc | +---------+---------+---------+ +---------+---------+ | Sig T | Sig L | | SVal L | SVal Vc | +---------+---------+---------+ +---------+---------+ | SInf T | SInf L | SInf V | | FrPr Vc | +---------+---------+---------+ +---------+ | SVal T | SVal L | SVal V | +---------+---------+---------+ Figure 17: Compression of NDN LoWPAN Data Message Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 18. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 |CID|EXT|FBI|CON|KLO|RSV| +---+---+---+---+---+---+---+---+ Figure 18: Dispatch format for compressed NDN Data messages CID: Context Identifier See Figure 5. EXT: Extension 0: No extension octet follows. 1: Extension octet "EXT_0" follows immediately. See Section 5.4.3. FBI: FinalBlockId TLV Gundogan, et al. Expires September 10, 2020 [Page 19] Internet-Draft ICN Adaptation to LoWPANs March 2020 0: The uncompressed message does not include a FinalBlockId TLV. 1: The uncompressed message does include a FinalBlockId and it is encoded according to Section 5.2. If the FinalBlockId TLV is not compressible, then the message MUST be sent uncompressed. CON: ContentType TLV 0: The uncompressed message does not include a ContentType TLV. 1: The uncompressed message does include a ContentType TLV. The Type field is removed from the compressed message. KLO: KeyLocator TLV 0: If the included SignatureType requires a KeyLocator TLV, then the KeyLocator represents a name and is compressed according to Section 5.2. If the the name is not compressible, then the message MUST be sent uncompressed. 1: If the included SignatureType requires a KeyLocator TLV, then the KeyLocator represents a KeyDigest. The Type field of this KeyDigest is removed. RSV: Reserved Must be set to 0. 5.4.3. Dispatch Extension The "EXT_0" octet follows the description in Section 4.1.1 and is illustrated in Figure 19. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+ Figure 19: EXT_0 format NCS: Name Compression Strategy 00: Names are compressed with the default name compression strategy (see Section 5.2). Gundogan, et al. Expires September 10, 2020 [Page 20] Internet-Draft ICN Adaptation to LoWPANs March 2020 01: Reserved. 10: Reserved. 11: Reserved. RSV: Reserved Must be set to 0. EXT: Extension 0: No extension octet follows. 1: A further extension octet follows immediately. 6. Space-efficient Message Encoding for CCNx 6.1. TLV Encoding The generic CCNx TLV encoding is described in [RFC8609]. Type and Length fields attain the common fixed length of 2 octets. The TLV encoding for CCNx LoWPAN is changed to the more space efficient encoding described in Section 5.1. Hence NDN and CCNx use the same compressed format for writing TLVs. 6.2. Name TLV Compression Name TLVs are compressed using the scheme already defined in Section 5.2 for NDN. If a Name TLV contains T_IPID, T_APP, or organizational TLVs, then the name remains uncompressed. 6.3. Interest Messages 6.3.1. Uncompressed Interest Messages An uncompressed Interest message uses the base dispatch format (see Figure 4) and sets the C as well as the M flag to "0" (Figure 20). "resv" MUST be set to 0. The Interest message is handed to the CCNx network stack without modifications. 0 1 ... 7 +---+---+-----------------------+ | 0 | 0 | resv | +---+---+-----------------------+ Figure 20: Dispatch format for uncompressed CCNx Interest messages Gundogan, et al. Expires September 10, 2020 [Page 21] Internet-Draft ICN Adaptation to LoWPANs March 2020 6.3.2. Compressed Interest Messages The compressed Interest message uses the extended dispatch format (Figure 5) and sets the C flag to "1" and the M flag to "0". If an Interest message contains TLVs that are not mentioned in the following compression rules, then this message MUST be sent uncompressed. In the default use case, the Interest message is compressed with the following minimal rule set: 1. The Type and Length fields of the CCNx Message TLV are elided and are obtained from the Fixed Header on decompression. The compressed CCNx LoWPAN Interest message is visualized in Figure 21. T = Type, L = Length, V = Value +--------------------------+ +--------------------------+ | Uncompr. Fixed Header | | Compr. Fixed Header | +--------------------------+ +--------------------------+ +--------+--------+--------+ +--------+ | ILT T | ILT L | ILT V | | ILT V | +--------+--------+--------+ +--------+ | MSGH T | MSGH L | MSGH V | | MSGH V | +--------+--------+--------+ +--------+ +--------+--------+ +--------+ | MSGT T | MSGT L | | Name V | +--------+--------+--------+ +--------+ | Name T | Name L | Name V | ==> | KIDR V | +--------+--------+--------+ +--------+ | KIDR T | KIDR L | KIDR V | | OBHR V | +--------+--------+--------+ +--------+--------+ | OBHR T | OBHR L | OBHR V | | PAYL L | PAYL V | +--------+--------+--------+ +--------+--------+ | PAYL T | PAYL L | PAYL V | | VALG L | VALG V | +--------+--------+--------+ +--------+--------+ | VALG T | VALG L | VALG V | | VPAY L | VPAY V | +--------+--------+--------+ +--------+--------+ | VPAY T | VPAY L | VPAY V | +--------+--------+--------+ Figure 21: Compression of CCNx LoWPAN Interest Message Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 22. Gundogan, et al. Expires September 10, 2020 [Page 22] Internet-Draft ICN Adaptation to LoWPANs March 2020 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 1 | 0 |CID|EXT|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|RSV| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 22: Dispatch format for compressed CCNx Interest messages CID: Context Identifier See Figure 5. EXT: Extension 0: No extension octet follows. 1: Extension octet "EXT_0" follows immediately. See Section 6.3.3. VER: CCNx protocol version in the fixed header 0: The Version field equals 1 and is removed from the fixed header. 1: The Version field is carried in-line. FLG: Flags field in the fixed header 0: The Flags field equals 0 and is removed from the Interest message. 1: The Flags field is carried in-line. PTY: PacketType field in the fixed header 0: The PacketType field is elided and assumed to be "PT_INTEREST" 1: The PacketType field is elided and assumed to be "PT_RETURN" HPL: HopLimit field in the fixed header 0: The HopLimit field is carried in-line 1: The HopLimit field is elided and assumed to be "1" FRS: Reserved field in the fixed header 0: The Reserved field is carried in-line Gundogan, et al. Expires September 10, 2020 [Page 23] Internet-Draft ICN Adaptation to LoWPANs March 2020 1: The Reserved field is elided and assumed to be "0" PAY: Optional Payload TLV 0: The Payload TLV is absent. 1: The Payload TLV is present and the type field is elided. ILT: Optional Hop-By-Hop InterestLifetime TLV See Section 6.3.2.1 for further details on the ordering of hop-by-hop TLVs. 0: No InterestLifetime TLV is present in the Interest message. 1: An InterestLifetime TLV is present with a fixed length of 1 octet and is encoded as described in Section 7. The type and length fields are elided. If a lifetime is not a valid time-value, then the lifetime is rounded up to the nearest valid time-value (see Section 7). MGH: Optional Hop-By-Hop MessageHash TLV See Section 6.3.2.1 for further details on the ordering of hop-by-hop TLVs. This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Interest MUST be sent uncompressed. 0: The MessageHash TLV is absent. 1: A T_SHA-256 TLV is present and the type as well as the length fields are removed. The length field is assumed to represent 32 octets. The outer Message Hash TLV is omitted. KIR: Optional KeyIdRestriction TLV This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Interest MUST be sent uncompressed. 0: The KeyIdRestriction TLV is absent. 1: A T_SHA-256 TLV is present and the type as well as the length fields are removed. The length field is assumed Gundogan, et al. Expires September 10, 2020 [Page 24] Internet-Draft ICN Adaptation to LoWPANs March 2020 to represent 32 octets. The outer KeyIdRestriction TLV is omitted. CHR: Optional ContentObjectHashRestriction TLV This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Interest MUST be sent uncompressed. 0: The ContentObjectHashRestriction TLV is absent. 1: A T_SHA-256 TLV is present and the type as well as the length fields are removed. The length field is assumed to represent 32 octets. The outer ContentObjectHashRestriction TLV is omitted. VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 0: No validation related TLVs are present in the Interest message. 1: Validation related TLVs are present in the Interest message. An additional octet follows immediately that handles validation related TLV compressions and is described in Section 6.3.2.2. RSV: Reserved Must be set to 0. 6.3.2.1. Hop-By-Hop Header TLVs Compression Hop-By-Hop Header TLVs are unordered. For an Interest message, two optional Hop-By-Hop Header TLVs are defined in [RFC8609], but several more can be defined in higher level specifications. For the compression specified in the previous section, the Hop-By-Hop TLVs are ordered as follows: 1. Interest Lifetime TLV 2. Message Hash TLV Note: Other Hop-By-Hop Header TLVs than those two remain uncompressed. 6.3.2.2. Validation Gundogan, et al. Expires September 10, 2020 [Page 25] Internet-Draft ICN Adaptation to LoWPANs March 2020 0 1 2 3 4 5 6 7 8 +-------+-------+-------+-------+-------+-------+-------+-------+ | ValidationAlg | KeyID | Reserved | +-------+-------+-------+-------+-------+-------+-------+-------+ Figure 23: Dispatch for Interset Validations ValidationALg: Optional ValidationAlgorithm TLV 0000: An uncompressed ValidationAlgorithm TLV is included. 0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. 0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. Additionally, a Sigtime TLV is inlined without a type and a length field. 0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. 0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. Additionally, a Sigtime TLV is inlined without a type and a length field. 0101: Reserved. 0110: Reserved. 0111: Reserved. 1000: Reserved. 1001: Reserved. 1010: Reserved. 1011: Reserved. 1100: Reserved. 1101: Reserved. 1110: Reserved. 1111: Reserved. KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV Gundogan, et al. Expires September 10, 2020 [Page 26] Internet-Draft ICN Adaptation to LoWPANs March 2020 00: The KeyId TLV is absent. 01: The KeyId TLV is present and uncompressed. 10: A T_SHA-256 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 32 octets. The outer KeyId TLV is omitted. 11: A T_SHA-512 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 64 octets. The outer KeyId TLV is omitted. The ValidationPayload TLV is present if the ValidationAlgorithm TLV is present. The type field is omitted. 6.3.3. Dispatch Extension The "EXT_0" octet follows the description in Section 4.1.1 and is illustrated in Figure 24. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+ Figure 24: EXT_0 format NCS: Name Compression Strategy 00: Names are compressed with the default name compression strategy (see Section 5.2). 01: Reserved. 10: Reserved. 11: Reserved. RSV: Reserved Must be set to 0. EXT: Extension 0: No extension octet follows. 1: A further extension octet follows immediately. Gundogan, et al. Expires September 10, 2020 [Page 27] Internet-Draft ICN Adaptation to LoWPANs March 2020 6.4. Content Objects 6.4.1. Uncompressed Content Objects An uncompressed Content object uses the base dispatch format (see Figure 4) and sets the C flag to "0" and the M flag to "1" (Figure 25). "resv" MUST be set to 0. The Content object is handed to the CCNx network stack without modifications. 0 1 ... 7 +---+---+-----------------------+ | 0 | 1 | resv | +---+---+-----------------------+ Figure 25: Dispatch format for uncompressed CCNx Content objects 6.4.2. Compressed Content Objects The compressed Content object uses the extended dispatch format (Figure 5) and sets the C flag as well as the M flag to "1". If a Content object contains TLVs that are not mentioned in the following compression rules, then this message MUST be sent uncompressed. By default, the Content object is compressed with the following base rule set: 1. The PacketType field is elided from the Fixed Header. 2. The Type and Length fields of the CCNx Message TLV are elided and are obtained from the Fixed Header on decompression. The compressed CCNx LoWPAN Data message is visualized in Figure 26. Gundogan, et al. Expires September 10, 2020 [Page 28] Internet-Draft ICN Adaptation to LoWPANs March 2020 T = Type, L = Length, V = Value +--------------------------+ +--------------------------+ | Uncompr. Fixed Header | | Compr. Fixed Header | +--------------------------+ +--------------------------+ +--------+--------+--------+ +--------+ | RCT T | RCT L | RCT V | | RCT V | +--------+--------+--------+ +--------+--------+ | MSGH T | MSGH L | MSGH V | | MSGH L | MSGH V | +--------+--------+--------+ +--------+--------+ +--------+--------+ +--------+ | MSGT T | MSGT L | | Name V | +--------+--------+--------+ +--------+ | Name T | Name L | Name V | ==> | EXPT V | +--------+--------+--------+ +--------+--------+ | PTYP T | PTYP L | PTYP V | | PAYL L | PAYL V | +--------+--------+--------+ +--------+--------+ | EXPT T | EXPT L | EXPT V | | VALG L | VALG V | +--------+--------+--------+ +--------+--------+ | PAYL T | PAYL L | PAYL V | | VPAY L | VPAY V | +--------+--------+--------+ +--------+--------+ | VALG T | VALG L | VALG V | +--------+--------+--------+ | VPAY T | VPAY L | VPAY V | +--------+--------+--------+ Figure 26: Compression of CCNx LoWPAN Data Message Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 27. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 1 | 1 |CID|EXT|VER|FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL| RSV | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 27: Dispatch format for compressed CCNx Content objects CID: Context Identifier See Figure 5. EXT: Extension 0: No extension octet follows. 1: Extension octet "EXT_0" follows immediately. See Section 6.4.3. Gundogan, et al. Expires September 10, 2020 [Page 29] Internet-Draft ICN Adaptation to LoWPANs March 2020 " of OSI which defines its seven layers and their functions. Sometimes used to help describe other networks. OSPFIGP Open Shortest-Path First Internet Gateway Protocol An experimental replacement for RIP. It addresses some problems of RIP and is based upon principles that have been well-tested in non-internet protocols. Often referred to simply as OSPF. packet The unit of data sent across a packet switching network. The term is used loosely. While some Internet literature uses it to refer specifically to data sent across a physical network, other literature views the Internet as a packet switching network and describes IP datagrams as packets. PC Personal Computer PCNFS Personal Computer Network File System POSIX Portable Operating System Interface Operating system based on UNIX. protocol A formal description of message formats and the rules two computers must follow to exchange those messages. Protocols can describe low-level details of machine-to-machine interfaces (e.g., the order in which bits and bytes are sent across a wire) or high-level exchanges between allocation programs (e.g., the way in which two programs transfer a file across the Internet). User Services Working Group [Page 20] RFC 1177 FYI Q/A - for New Internet Users August 1990 PSC Pittsburgh Supercomputing Center PSCNET Pittsburgh Supercomputing Center Network RFC The Internet's Request for Comments documents series The RFCs are working notes of the Internet research and development community. A document in this series may be on essentially any topic related to computer communication, and may be anything from a meeting report to the specification of a standard. RIP Routing Interchange Protocol One protocol which may be used on internets simply to pass routing information between gateways. It is used on may LANs and on some of the NSFnet regional networks. RJE Remote Job Entry The general protocol for submitting batch jobs and retrieving the results. RLOGIN Remote Login A service on internets very similar to TELNET. RLOGIN was invented for use between Berkeley Unix systems on the same LAN at a time when TELNET programs didn't provide all the services users wanted. Berkeley plans to phase it out. RPC Remote Procedure Call An easy and popular paradigm for implementing the client-server model of distributed computing. server A computer that shares its resources, such as printers and files, with other computers on the network. An example of this is a Network Files System (NFS) Server which shares its disk space with a workstations that does not have a disk drive of its own. SESQUINET Sesquicentennial Network Texas-based regional network named for their sesquicentennial celebration SMTP Simple Mail Transfer Protocol The Internet standard protocol for transferring electronic mail messages from one computer to another. SMTP specifies how two mail systems interact and the format of control messages they exchange to transfer mail. User Services Working Group [Page 21] RFC 1177 FYI Q/A - for New Internet Users August 1990 SNA System Network Architecture IBM's data communications protocol. subnet A portion of a network, which may be a physically independent network, which shares a network address with other portions of the network and is distinguished by a subnet number. A subnet is to a network what a network is to an internet. subnet number A part of the internet address which designates a subnet. It is ignored for the purposes internet routing, but is used for intranet routing. SURANET Southeastern Universities Research Association Network An NSFNET regional network. T1 A term for a digital carrier facility used to transmit a DS-1 formatted digital signal at 1.544 megabits per second. T3 A term for a digital carrier facility used to transmit a DS-3 formatted digital signal at 44.746 megabits per second. TCP Transmission Control Protocol A transport layer protocol for the Internet. It is a connection oriented, stream protocol defined by RFC 793. TCP/IP Transmission Control Protocol/Internet Protocol This is a common shorthand which refers to the suite of application and transport protocols which run over IP. These include FTP, Telnet, SMTP, and UDP (a transport layer protocol). Telenet A public packet-switching network operated by US Sprint. Telnet The Internet standard protocol for remote terminal connection service. Telnet allows a user at one site to interact with a remote timesharing system at another site as if the user's terminal was connected directly to the remote computer. Token Ring A type of LAN. Examples are IEEE 802.5, ProNET-10/80 and FDDI. The term "token ring" is often used to denote 802.5 Tymnet A public packet-switching network operated by McDonnell Douglas Network Systems Company. User Services Working Group [Page 22] RFC 1177 FYI Q/A - for New Internet Users August 1990 UDP User Datagram Protocol A transport layer protocol for the Internet. It is a datagram protocol which simply adds a level of reliability to IP datagrams. It is defined by RFC 768. ULTRIX UNIX-based operating system for Digital Equipment Corporation computers. UNIX An operating system developed by Bell Laboratories that supports multiuser and multitasking operations. UUCP UNIX-to-UNIX Copy Program A protocol used for communication between consenting UNIX systems. VMS Virtual Memory System A Digital Equipment Corporation operating system. WAN Wide Area Network WESTNET One of the National Science Foundation funded regional TCP/IP networks that covers the states of Arizona, Colorado, New Mexico, Utah, and Wyoming. WHOIS An Internet program which allows users to query a database of people and other Internet entities, such as domains, networks, and hosts, kept at the NIC. The information for people shows a person's company name, address, phone number and email address. XNS Xerox Network System A data communications protocol developed by Xerox. It uses Ethernet to move the data between computers. X.25 A data communications protocol developed to describe how data passes into and out of public data communications networks. The public networks such as Telenet and Tymnet, use X.25 to interface to customer computers. 12. Security Considerations Security issues are not discussed in this memo. User Services Working Group [Page 23] RFC 1177 FYI Q/A - for New Internet Users August 1990 13. Authors' Addresses Gary Scott Malkin FTP Software, Inc. 26 Princess Street Wakefield, MA 01880 Phone: (617) 246-0900 EMail: gmalkin@ftp.com April N. Marine SRI International Network Information Systems Center 333 Ravenswood Avenue, EJ294 Menlo Park, CA 94025 Phone: (415) 859-5318 EMail: APRIL@NIC.DDN.MIL Joyce K. Reynolds USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695 Phone: (213) 822-1511 EMail: jkrey@isi.edu User Services Working Group [Page 24]