home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-exp-rupp-00.txt < prev    next >
Text File  |  1997-05-01  |  17KB  |  473 lines
  1.  
  2. INTERNET-DRAFT         EXPIRES OCTOBER 1997        INTERNET-DRAFT
  3. Network Working Group                                     Heiko W.Rupp
  4. INTERNET-DRAFT
  5. Experimental                                                29.04.1997
  6.  
  7.  
  8.          A Protocol for the Transmission of Net News Articles
  9.                            over IP multicast.
  10.                     <draft-rfced-exp-rupp-00.txt>
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    This document is an Internet-Draft.  Internet-Drafts are working
  16.    documents of the Internet Engineering task Force (IETF), its areas,
  17.    and its working groups.  Note that other groups may also distribute
  18.    working documents as Internet-Drafts.
  19.  
  20.    Internet-Drafts are draft documents valid for a maximum of six
  21.    months and may be updated, replaced, or obsoleted by other
  22.    documents at any time.  It is inappropriate to use Internet-Drafts
  23.    as reference material or to cite them other than as "work in
  24.    progress".
  25.  
  26.    To learn the current status of any Internet-Draft, please check the
  27.    "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
  28.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  29.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  30.    ftp.isi.edu (US West Coast).
  31.  
  32.  
  33. Abstract
  34.  
  35.    This protocol provides a way to use the IP multicast infrastructure
  36.    to transmit NetNews articles between news servers. Doing so will
  37.    reduce the bandwidth that is actually needed for transmission via
  38.    NNTP. This does not affect how news reading clients communicate with
  39.    servers.
  40.  
  41. Overview and Rationale
  42.  
  43.    NetNews are bulk data that are produced in large quantities every day
  44.    around the world. Distribution of NetNews on the Internet are usually
  45.    distributed with NNTP[1]. In order to get a fast and redundant
  46.    distribution many news servers communicate with many others, thus
  47.    imposing a higher load on the underlying network than necessary.
  48.  
  49.    Assume the following scenario:
  50.  
  51.                              +---------  R1
  52.                             /
  53.              S -- A ------- B  --------  R2
  54.                             \
  55.                               +--------- R3
  56.  
  57.    A sender S which wants to transmit articles via NNTP to receivers
  58.    R1...R3 will thus transmit them three times across the link from A to
  59.    B.
  60.  
  61.    With IP Multicast[2], an efficient way to distribute datagrams to
  62.    groups of users exists in the Internet. Thus articles would traverse
  63.    the link A to B only once, thus reducing load on that link.
  64.  
  65.    This cannot be done with existing news transfer technology, as it is
  66.  
  67.  
  68.  
  69. Rupp                                                            [Page 1]
  70.  
  71. =0C
  72. I/D                 NETNEWS OVER IP MULTICAST           29 April 1997
  73.  
  74.  
  75.    based on TCP[10] which cannot be multicasted.  The protocol described
  76.    in this memo is designed to put news articles into datagrams and
  77.    distribute them via IP multicast to receivers that are interested in
  78.    the specific newsgroup. For more information about NetNews, refer to
  79.    [7] and [1].
  80.  
  81.    In the rest of this memo I will refer to the protocol as ``Multicast
  82.    News Transport Protocol'' (Mcntp).
  83.  
  84. Protocol overview
  85.  
  86.    This paragraph will show how news articles are propagated with Mcntp.
  87.    Basically, three parties are involved:
  88.  
  89.  
  90.    +    Multicast directory service, MD, coordinates the assignment
  91.         between multicast and news groups.
  92.  
  93.    +    A Multicast sender, MS, that sends news articles over an
  94.         IP multicast infrastructure
  95.  
  96.    +    A Multicast receiver, MR, gets packets from the IP multicast
  97.         infrastructure and processes them further.
  98.  
  99.    So this can be seen as follows:
  100.  
  101.                directory       +---------+    directory
  102.              +------------- >  |         | ----------------+
  103.             \|/                |   MD    |                \|/
  104.          +---------+           |         |             +--------+
  105.          |         |           +---------+             |        |
  106.          |   MS    |                                   |   MR   |
  107.          |         | ------------ articles ------->    |        |
  108.          +---------+                                   +--------+
  109.  
  110.    MS and MR can be implemented into existing news server software, or
  111.    can be implemented as separate processes that communicate with the
  112.    news servers (e.g. via NNTP); this does not matter to the protocol.
  113.  
  114.    MD can either be implemented within MS, or as separate processes that
  115.    communicate with each other. A practical way is to have on MD per
  116.    sender host so that communication between MD and MS is fast and
  117.    reliable, while not too many resources are needed.
  118.  
  119.    The protocol itself consist of two parts that will be presented in
  120.    the next two chapters -- Distribution of articles and the directory
  121.    service.
  122.  
  123.  
  124.  
  125.  
  126. Rupp                                                            [Page 2]
  127.  
  128. =0C
  129. I/D                NETNEWS OVER IP MULTICAST           29 April 1997
  130.  
  131.  
  132. Packet format -- Distribution of articles
  133.  
  134.    To send articles via IP multicast, they have to be encapsulated into
  135.    UDP packets. The following diagram shows how this can be done:
  136.  
  137.          +---------------------------------------+
  138.          |                 Magic                 |
  139.          +----+----+---------+---------+---------+
  140.          | Ver|Rev |  Comp   |  Crypt  |  Offset |
  141.          +----+----+---------+---------+---------+
  142.          |            Original length            |
  143.          +---------------------------------------+
  144.          |             Length as sent            |
  145.          +---------------------------------------+
  146.          |                  Crc                  |
  147.          +---------------------------------------+
  148.          |              Message-id               |
  149.          +---------------------------------------+
  150.          |               Data                    |
  151.          +---------------------------------------+
  152.  
  153.    All entries are in network byte order.  The fields have the following
  154.    meaning and types:
  155.  
  156.  
  157.     +    Magic (32-bit): The String ``McNt''
  158.  
  159.     +    Ver (4-bit): Protocol version -- currently 1
  160.  
  161.     +    Rev (4-bit): Protocol revision -- currently 1
  162.  
  163.     +    Comp (8-bit): Compression method used. Currently are only 2
  164.          methods defined:
  165.  
  166.           0    Article is not compressed
  167.  
  168.           1    Article is compressed via zlib [8]
  169.  
  170.     +    Crypt (8-bit): Encryption method used. See below
  171.  
  172.     +    Offset (8-bit): Offset of article data from packet start
  173.  
  174.     +    Original length (32-bit): Length of article before compression
  175.          and encryption
  176.  
  177.     +    Length as sent (32-bit):
  178.  
  179.     +    Length of the ``Data'' field (see below)
  180.  
  181.  
  182.  
  183. Rupp                                                            [Page 3]
  184.  
  185. =0C
  186. I/D                 NETNEWS OVER IP MULTICAST           29 April 1997
  187.  
  188.  
  189.     +    Crc (32-bit): Checksum over the original articles. See also
  190.          below.
  191.  
  192.     +    Message-ID: The message id of the article in the form it is
  193.          defined in RFC 1036 [7], terminated by a null byte.
  194.  
  195.     +    Data: The article data after possible compression and
  196.          encryption.
  197.  
  198.    This memo does not specify a encryption method for the case that the
  199.    field ``Crypt'' is set to anything other than 0; the involved parties
  200.    (i.e. the senders of encrypted news and their receivers) have to
  201.    agree on a method they want to use. If encryption and compression is
  202.    used then the article data is first to be compressed and then the
  203.    result to be encrypted.
  204.  
  205.    The checksum is computed over the original article data (i.e. before
  206.    possible compression and encryption) by the algorithm of IEEE
  207.    Std1003.2-1992 which is also used in 4.4 BSD cksum(1) tool. See also
  208.    [11].
  209.  
  210.    To send an article off, it is encapsulated and then just sent to the
  211.    appropriate multicast group. There is no feedback from the receiver
  212.    to the sender when an article is received.
  213.  
  214. Directory service
  215.  
  216.    In order to get a relation between newsgroups and multicast groups, a
  217.    directory service exists; this has been referenced as MD above.  When
  218.    a sender MS wants to propagate a news group, it asks the directory
  219.    service for a multicast group it can use to distribute articles,
  220.    waits for the reply, and starts to send. The directory server
  221.    registers this group in its tables and periodically distributes this
  222.    table over IP multicast. For this purpose, the multicast group
  223.    ``mcntp-directory.mcast.net'' has been officially been assigned by
  224.    the IANA. The UDP port which announcements are sent to, has
  225.    officially been assigned by the IANA as UDP port number 5418 with the
  226.    name ``mcntp''.
  227.  
  228.    Announcements should not be sent too often to keep traffic low, but
  229.    often enough that new receivers don't have to wait to long to be able
  230.    to receive articles. Once a minute is assumed to be a good value
  231.    here.  Announcements can be sent less often if they are transmitted
  232.    immediately after a change in the directory.
  233.  
  234.    If more than one directory server is involved (e.g. if there is more
  235.    than one sender site), the directory servers have to listen to
  236.    announcement packets on ``mcntp-directory.mcast.net''. If it does not
  237.  
  238.  
  239.  
  240. Rupp                                                            [Page 4]
  241.  
  242. =0C
  243. I/D                 NETNEWS OVER IP MULTICAST           29 April 1997
  244.  
  245.  
  246.    receive a packet after five times the waiting period (e.g., five
  247.    minutes) it can consider itself alone on the net and can choose the
  248.    multicast groups as it wishes. If it does receive a packet, it must
  249.    register the contained groups in its tables and has to select new
  250.    groups so that different newsgroups are not mapped on the same
  251.    multicast group.
  252.  
  253.    When a receiver (MR) wants to receive a newsgroup, it listens on
  254.    ``mcntp-directory.mcast.net'' for announcements, parses them, and
  255.    then joins the appropriate multicast groups.
  256.  
  257.    Multicast groups that are no longer in use (e.g. because the sender
  258.    has stopped working) must be removed from the announcement.
  259.  
  260.    The format of those announcement packets is:
  261.  
  262.          +-----------+------+-----+--------+
  263.          |   Magic   | Vers | Rev | Offset |
  264.          +-----------+------+-----+--------+
  265.          |             Length              |
  266.          +---------------------------------+
  267.          |               Crc               |
  268.          +---------------------------------+
  269.          |            Sender-ID            |
  270.          +-----------------+------+---+-----------+       -+
  271.          | Multicast group | Port |TTL| Newsgroup |        |
  272.          +-----------------+------+---+-----------+        |
  273.           ...  repeat ...                                  |  NG lines
  274.          +-----------------+------+---+-----------+        |
  275.          | Multicast group | Port |TTL| Newsgroup |        |
  276.          +-----------------+------+---+-----------+       -+
  277.  
  278.    All numbers are in network byte order.  The fields have the following
  279.    meaning and types:
  280.  
  281.  
  282.        +    Magic (16-bit): The Bytes 0xab
  283.  
  284.        +    Vers (4-bit): Protocol version
  285.  
  286.        +    Rev (4-bit): Protocol revision (currently 1)
  287.  
  288.        +    Offset (8-bit): Offset of NG-lines from packet start.
  289.  
  290.        +    Length (32-bit): Total packet length.
  291.  
  292.        +    Crc (32-bit): Checksum over the rest of the packet.
  293.  
  294.  
  295.  
  296.  
  297. Rupp                                                            [Page 5]
  298.  
  299. =0C
  300. I/D               NETNEWS OVER IP MULTICAST           29 April 1997
  301.  
  302.  
  303.        +    Sender-ID  : Identification of sender host, terminated by a
  304.             null byte (see below).
  305.  
  306.        +    Multicast group (32-bit *): The associated multicast group
  307.  
  308.        +    Port (8-bit): UDP Port to use for this group
  309.  
  310.        +    TTL (8-bit): Time to live for multicast packets.
  311.  
  312.        +    Newsgroup: Name of the Newsgroup in wildmat(3) format,
  313.             terminated by a null byte.
  314.  
  315.    The protocol version (Vers) is currently 1 for IPv4 and 11 for IPv6.
  316.    The multicast group field (*) is 32 bit in size for IPv4 and 128-bit
  317.    for IPv6 in size.
  318.  
  319.    The lenght field is 32 bit in size to support IPv6 jumbo datagrams.
  320.  
  321.    The sender-ID is normally the fully qualified domain name of the
  322.    hosts that sends the announcement. As is common practice with
  323.    NetNews, this can also be the (possibly shorter) entry that the host
  324.    puts in the ``Path:'' header when an article passes through it.
  325.  
  326.    The checksum is computed over all lines with newsgroup to multicast
  327.    group relations in the packet by the algorithm of IEEE Std1003.2-1992
  328.    which is also used in 4.4 BSD cksum(1) tool. See also [11].
  329.  
  330.    The lines with newsgroup to multicast group relations are repeated as
  331.    often as needed to announce all groups. The TTL can be used by
  332.    clients to find out if packets that come from this source can reach
  333.    them, or if the sender is too far away.  Note that all entries have
  334.    to fit into one UDP packet.
  335.  
  336. Reliability Considerations
  337.  
  338.    As UDP is a unreliable service, provisions for reliable distribution
  339.    of articles are needed. There exist some approaches to reliable
  340.    multicast (XTP [4], KLG [5] or RMTP [6]) which all suffer from some
  341.    problem or other. Specifically, additional hard- or software is
  342.    needed and usually requires kernel modification.
  343.  
  344.    As there is already a reliable transport of NetNews via NNTP, there
  345.    is no need for a reliable transport via IP multicast: articles need
  346.    not be in order, so it is no problem if one is missing in the
  347.    multicast. Since articles need not arrive in order, lost or missing
  348.    articles can easily be transmitted via an additional NNTP feed.
  349.  
  350.    As UDP packets can be at maximum 64kBytes in size and every Mcntp
  351.  
  352.  
  353.  
  354. Rupp                                                            [Page 6]
  355.  
  356. =0C
  357. I/D                 NETNEWS OVER IP MULTICAST           29 April 1997
  358.  
  359.  
  360.    packet has to fit in one UDP packet, there is no provision given to
  361.    distribute news articles larger than about 63kBytes in size (other
  362.    than compressing them). This does not matter much in practise as
  363.    recent research has shown that more than 95% off all news articles
  364.    are smaller 64kBytes [9]. The remaining 5% can still be transferred
  365.    via NNTP. Some hosts may have problems in receiving UDP packets as
  366.    large as 64kBytes, so in practical use article sizes of 16kBytes
  367.    would be appropriate.
  368.  
  369. Summary
  370.  
  371.    The distribution of NetNews articles via IP multicast can be a way to
  372.    decrease the network bandwidth used to distribute them.  Articles are
  373.    delivered fast via a nonreliable protocol; later, the holes are
  374.    filled via a reliable, already existing protocol. Compression of
  375.    articles can further reduce the network Load. With encryption private
  376.    news groups can be established on a public IP multicast
  377.    infrastructure. A prototype of a reference implementation already
  378.    shows that Mcntp is fast and can be used as an alternative to
  379.    classical transports.
  380.  
  381. Security Considerations
  382.  
  383.    This memo touches security only as far as the provision for
  384.    encryption of article data is given in the protocol.
  385.  
  386.    No further security issues are discussed.
  387.  
  388. References
  389.  
  390.  
  391. [1]  RFC 977 -- B. Kantor, P. Lapsley, "Network News Transfer Protocol:
  392.      A Proposed Standard for the Stream-Based Transmission of News".
  393.  
  394. [2]  RFC 1112 -- S. Deering, "Host extensions for IP multicasting",
  395.      08/01/1989.
  396.  
  397. [3]  RFC 768 -- J. Postel, "User Datagram Protocol", 08/28/1980.
  398.  
  399. [4]  XTP -- W. T. Strayer, D.J. Dmepsey, B.C. Weaver, "XTP: The Xpress
  400.      Transfer Protocol", Addison-Wesley
  401.  
  402. [5]  KLG -- M. Hofmann, "Zuverlaessige Kommunikation in heterogenen
  403.      Netzen", Thesis at "Institut fuer Telematik, CS Dept. Univ
  404.      Karlsruhe"
  405.  
  406. [6]  RMTP -- Lin, John C., Paul Sanjoy, "RMTP: A Reliable Multicast
  407.      Transport Protocol".
  408.  
  409.  
  410.  
  411. Rupp                                                            [Page 7]
  412.  
  413. =0C
  414. I/D                 NETNEWS OVER IP MULTICAST           29 April 1997
  415.  
  416.  
  417. [7]  RFC 1036 -- M. Horton, R. Adams, "Standard for interchange of
  418.      USENET messages", 12/01/1987.
  419.  
  420. [8]  RFC 1950 -- L. Deutsch, J. Gailly, "ZLIB Compressed Data Format
  421.      Specification version 3.3", 05/23/1996.
  422.  
  423. [9]  http://www.xlink.net/~hwr/histo/ -- Some Statistics about size dis-
  424.      tribution of NetNews
  425.  
  426. [10] RFC 793 -- J. Postel, "Transmission Control Protocol", 09/01/1981.
  427.  
  428. [11] Dilip V. Sarwate, "Computation of Cyclic Redundancy Checks Via
  429.      Table Lookup", Communications of the ACM, August 1988.
  430.  
  431. Author's Address
  432.  
  433.    Heiko W.Rupp
  434.    Gerwigstr. 5
  435.    D-76131 Karlsruhe
  436.  
  437.    Phone: +49 721 9661524
  438.  
  439.    EMail: hwr@pilhuhn.de
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468. Rupp                                                            [Page 8]
  469.  
  470. INTERNET-DRAFT           EXPIRES OCTOBER 1997        INTERNET-DRAFT
  471.  
  472.  
  473.