[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

      Network Working Group                                       P. Johansson
      Internet-Draft                                  Congruent Software, Inc.
      <draft-ietf-ip1394-mcap-00.txt>
      Expires: October, 1998
      
      
      
             Multicast Channel Allocation Protocol (MCAP) for IEEE 1394
      
      
      STATUS OF THIS DOCUMENT
      
      This docuent is an Internet-Draft. Internet-Drafts are working
      docuents of the Internet Engineering Task Force (IETF), its areas, and
      its working groups. Note that other groups ay also distribute working
      docuents as Internet-Drafts.
      
      Internet-Drafts are draft docuents valid for a maximum of six months
      and ay be updated, replaced, or obsoleted by other documents at any
      tie. It is inappropriate to use Internet-Drafts as reference material
      or to cite the other than as "work in progress."
      
      To view the entire list of current Internet-Drafts, please check the
      "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
      Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
      unnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
      ftp.isi.edu (US West Coast).
      
      ABSTRACT
      
      This docuent specifies how IP-capable Serial Bus devices may allocate
      IEEE 1394 channel nuber(s) for use in the multicast transmission of IP
      datagras. It defines the necessary methods, data structures and codes
      for that purpose.
      
      See also the ost recent revision of draft-ietf-ip1394-ipv4 for a
      specification of the transport of IPv4 datagras over IEEE 1394.
      
      CAUTION: This is a WORKING DOCUMENT of the IETF IP/1394 group; soe
      parts reflect rough consensus achieved at the 41st IETF eeting in Los
      Angeles, other parts reflect the editor's distillation of coments on
      the reflector since then and still other parts are new contributions to
      the evolution of MCAP. Until subsequent revisions of this docuent are
      posted that ore clearly identify agreed areas, the reader should
      consider this a work in progress very uch subject to revision. This
      docuent is not yet adopted by the IP/1394 working group.
      
      
      
      
      
      
      
      
      
      
      Expire: October, 1998                                           [Page 1]


      Internet-Draft 00              1394 MCAP                     April 1998
      
      
      TABLE OF CONTENTS
      
      1. INTRODUCTION.......................................................3
      2. DEFINITIONS AND NOTATION...........................................3
         2.1 Conforance....................................................3
         2.2 Glossary.......................................................4
         2.3 Abbreviations..................................................4
      3. CHANNEL ALLOCATION MANAGER.........................................5
      4. MCAP MESSAGE FORMAT................................................5
      5. MCAP OPERATIONS....................................................7
         5.1 Advertiseent of channel mappings..............................8
         5.2 Request for channel allocation.................................8
         5.3 Error response to channel allocation...........................9
         5.4 Release of unneeded channel(s).................................9
         5.5 Solicitation of the channel ap...............................10
         5.6 Periodic refresh of channel allocation(s).....................10
      6. SECURITY CONSIDERATIONS...........................................11
      7. ACKNOWLEDGEMENTS..................................................11
      8. REFERENCES........................................................11
      9. EDITOR’S ADDRESS..................................................12
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      Expires: October, 1998                                          [Page 2]


      Internet-Draft 00              1394 MCAP                     April 1998
      
      
      1. INTRODUCTION
      
      This docuent specifies how IP-capable Serial Bus devices may allocate
      IEEE 1394 channel nuber(s) for use in the multicast transmission of IP
      datagras. It defines the necessary methods, data structures and codes
      for that purpose.
      
      The group of IEEE standards and suppleents, draft or approved, related
      to IEEE Std 1394-1995 is hereafter referred to either as 1394 or as
      Serial Bus.
      
      The draft specification for the transport of IPv4 datagras over 1394,
      draft-ietf-ip1394-ipv4, requires broadcast and multicast IP datagrams to
      be transported within 1394 asynchronous streas. Before an asynchronous
      strea may be used it is necessary to allocate a 1394 resource, a
      channel nuber. The IPv4 draft specification describes how a channel
      nuber is allocated for all broadcast IP datagrams; this same channel
      nuber is also used, by default, for multicast traffic.
      
      In cases where it is desirable to use a different channel nuber for
      particular multicast groups, methods are needed to allocate a channel
      nuber, advertise its existence and ultimately deallocate the channel
      nuber when it is no longer needed. This document describes such methods
      and naes them "multicast channel allocation protocol" (MCAP).
      
      Although the definition of MCAP is otivated by the particular
      requireents of 1394, the methods are extensible to other link media.
      
      CAUTION: This is a WORKING DOCUMENT of the IETF IP/1394 group; soe
      parts reflect rough consensus achieved at the 41st IETF eeting in Los
      Angeles, other parts reflect the editor's distillation of coments on
      the reflector since then and still other parts are new contributions to
      the evolution of MCAP. Until subsequent revisions of this docuent are
      posted that ore clearly identify agreed areas, the reader should
      consider this a work in progress very uch subject to revision. This
      docuent is not yet adopted by the IP/1394 working group.
      
      2. DEFINITIONS AND NOTATION
      
      2.1 Conforance
      
      When used in this docuent, the keywords "may", "optional",
      "recomended", "required", "shall" and "should" differentiate levels of
      requireents and optionality and are to be interpreted as described in
      RFC 2119.
      
      Several additional keywords are eployed, as follows:
      
      expected: A keyword used to describe the behavior of the hardware or
      software in the design odels assumed by this standard. Other hardware
      and software design odels may also be implemented.
      
      ignored: A keyword that describes bits, octets, quadlets or fields whose
      values are not checked by the recipient.
      
      
      Expires: October, 1998                                          [Page 3]


      Internet-Draft 00              1394 MCAP                     April 1998
      
      
      
      reserved: A keyword used to describe objects---bits, octets, quadlets
      and fields---or the code values assigned to these objects in cases where
      either the object or the code value is set aside for future
      standardization. Usage and interpretation ay be specified by future
      extensions to this or other standards. A reserved object shall be zeroed
      or, upon developent of a future standard, set to a value specified by
      such a standard. The recipient of a reserved object shall not check its
      value. The recipient of an object defined by this standard as other than
      reserved shall check its value and reject reserved code values.
      
      2.2 Glossary
      
      The following ters are used in this standard:
      
      bus ID: A 10-bit nuber that uniquely identifies a particular bus within
      a group of ultiple interconnected buses. The bus ID is the most
      significant portion of a node's 16-bit node ID. The value 0x3FF
      designates the local bus; a node shall respond to requests addressed to
      its 6-bit physical ID if the bus ID in the request is either 0x3FF or
      the bus ID explicitly assigned to the node.
      
      IP datagra: An Internet message that conforms to the format specified
      by RFC 791.
      
      node ID: A 16-bit nuber that uniquely identifies a Serial Bus node
      within a group of ultiple interconnected buses. The most significant 10
      bits are the bus ID and the least significant 6 bits are the physical
      ID.
      
      octet: Eight bits of data.
      
      packet: Any of the 1394 priary packets; these may be read, write or
      lock requests (and their responses) or strea data. The term "packet" is
      used consistently to differentiate 1394 packets fro ARP
      requests/responses or IP datagras.
      
      physical ID: On a particular bus, this 6-bit nuber is dynamically
      assigned during the self-identification process and uniquely identifies
      a node on that bus.
      
      quadlet: Four octets, or 32 bits, of data.
      
      strea packet: A 1394 primary packet with a transaction code of 0x0A
      that contains a block data payload. Strea packets may be either
      asynchronous or isochronous according to the type of 1394 arbitration
      eployed.
      
      2.3 Abbreviations
      
      The following are abbreviations that are used in this standard:
      
         CAM    Channel allocation anager
         MCAP   Multicast channel allocation protocol
      
      
      Expires: October, 1998                                          [Page 4]


      Internet-Draft 00              1394 MCAP                     April 1998
      
      
         IP     Internet protocol (within the context of this docuent, IPv4)
      
      3. CHANNEL ALLOCATION MANAGER
      
      MCAP requires the presence of a channel allocation anager (CAM) to
      process requests, allocate or deallocate Serial Bus channel nubers and
      advertise the apping from group addresses to their corresponding
      channels.
      
      The identity of the CAM and the ethod of its selection have not yet
      been discussed by the working group.
      
      Consensus has been reached that the CAM listens for essages (whose
      forat is described below) on the default multicast channel specified by
      the NETWORK_CHANNELS register and transits advertisements and other
      responses on the sae channel. The details of CAM operations are
      described in section 5.
      
      4. MCAP MESSAGE FORMAT
      
      MCAP essages, whether sent by a multicast source or recipient or the
      CAM, share a comon format illustrated below. The first eight octets of
      the essage are fixed; the remainder consists of variable-length tuples,
      each of which encodes inforation about a particular multicast group.
      
                              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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |             length            |            checksu           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |        bus_ID       |         reserved        |     opcode    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +                          essage data                         +
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
                           Figure 5 - MCAP essage format
      
      Field usage in an MCAP essage is as follows:
      
         length: This field shall contain the size, in octets, of the entire
         MCAP essage.
      
         checksu: This field shall contain a checksum calculated on the
         entire MCAP essage. The checksum shall be one's complement of the
         su of all the 16-bit words in the message; arithmetic overflow is
         discarded. For the purpose of calculating the checksu, the checksum
         field is treated as if zero.
      
         bus_ID: This field shall specify the 10-bit bus ID for which
         inforation in the MCAP message is valid. The value of bus_ID shall
         be equal to the ost significant 10 bits of the sender's NODE_IDS
         register.
      
      
      Expires: October, 1998                                          [Page 5]


      Internet-Draft 00              1394 MCAP                     April 1998
      
      
      
         opcode: This field shall have one of the values specified by table 1
         below.
      
                            Table 1 - MCAP opcode values
      
          opcode    Nae      Comment
         +----------------------------------------------------------------+
         |   0   | Advertise | Sent by the CAM to broadcast the current   |
         |       |           | apping from each group address to its      |
         |       |           | corresponding channel nuber.               |
         |   1   |  Request  | Sent by a multicast source to request the  |
         |       |           | allocation of a channel nuber or to        |
         |       |           | refresh the reaining lifetime of a         |
         |       |           | channel nuber allocation.                  |
         |   2   |  Release  | Optionally sent by a multicast source to   |
         |       |           | release a channel nuber at a future time.  |
         |   3   |   Error   | Sent by the CAM when it is unable to       |
         |       |           | satisfy a channel nuber allocation         |
         |       |           | request.                                   |
         |   4   |  Solicit  | Sent to request the CAM advertise the      |
         |       |           | current channel apping(s) as soon as       |
         |       |           | possible.                                  |
         +----------------------------------------------------------------+
      
         essage data: The remainder of the MCAP message is variable in length
         and shall consist of zero or ore group address descriptors with the
         forat illustrated below.
      
                              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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     length    |      type     |            reserved           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   expiration  |    channel    |     speed     |     status    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                           bandwidth                           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +                         group_address                         +
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
                   Figure 5 - MCAP group address descriptor forat
      
         length: This field shall contain the size, in octets, of the MCAP
         group address descriptor.
      
         type: This field shall have a value of one, which indicates a group
         address descriptor.
      
         expiration: The usage of this field varies according to opcode. For
         solicit and error essages the expiration field shall be ignored.
         Otherwise this field shall contain a tie-stamp, in seconds, that
      
      
      Expires: October, 1998                                          [Page 6]


      Internet-Draft 00              1394 MCAP                     April 1998
      
      
         specifies a future tie for the release of the channel number
         specified by channel. Tie is expressed in terms of the
         CYCLE_TIME.seconds and a atch occurs when expiration equals the most
         significant seven bits of the CYCLE_TIME register.
      
         channel: This field shall specify either a valid channel nuber, in
         the range zero to 63 inclusive, or else indicate an invalid channel
         nuber with a value of 0xFF. All other values are reserved. The usage
         of this field varies according to opcode, as shown in the table
         below.
      
                    Operation   Usage of channel
                  +----------------------------------------------+
                  | Advertise | Channel nuber allocated for the |
                  |           | multicast group_address          |
                  |  Request  | Suggested channel nuber (hint)  |
                  |  Release  | Ignored                          |
                  |   Error   | Ignored                          |
                  |  Solicit  | Ignored                          |
                  +----------------------------------------------+
      
         speed: This field shall be ignored except for advertise and request
         essages, in which case it shall specify the speed at which stream
         packets for the indicated channel are transitted. The encoding used
         for speed is specified by the table below; all values not specified
         are reserved.
      
                                    Value   Speed
                                  +---------------+
                                  |   0   |  S100 |
                                  |   1   |  S200 |
                                  |   2   |  S400 |
                                  |   3   |  S800 |
                                  |   4   | S1600 |
                                  |   5   | S3200 |
                                  +---------------+
      
         status: This field shall be ignored except for error essages, in
         which case it shall characterize the reason(s) the CAM did not
         allocate a requested channel nuber. The encoding for this field is
         yet to be deterined.
      
         bandwidth: This field shall be ignored; it is allocated in the group
         address descriptor to accomodate future extensions to MCAP that
         specify quality of service and utilize the isochronous capabilities
         of Serial Bus.
      
         group_address: This variable length field shall specify the IP
         address of a particular multicast group. The length of group_address,
         in octets, is derived fro the length of the group address descriptor
         by subtracting 12 fro the length field.
      
      5. MCAP OPERATIONS
      
      
      
      Expires: October, 1998                                          [Page 7]


      Internet-Draft 00              1394 MCAP                     April 1998
      
      
      MCAP is a cooperative protocol iplemented by multicast senders and
      recipients and the CAM. The participants exchange essages over the
      default multicast channel used by all IP-capable nodes on a particular
      Serial Bus.
      
      The bus_ID field in all MCAP essages shall be equal to the most
      significant 10 bits of the sender's NODE_IDS register.
      
      5.1 Advertiseent of channel mappings
      
      The CAM shall periodically broadcast an advertiseent of all multicast
      group addresses allocated a channel nuber that differs from the default
      multicast channel number. An advertisement shall consist of a single
      MCAP essage with an opcode of zero which contains zero or more group
      address descriptors (one for each group address assigned a channel
      nuber other than that specified by the NETWORK_CHANNELS register).
      
      Within each group address descriptor, the group_address and channel
      fields associate a multicast group address with a Serial Bus channel
      nuber. More than one multicast group address may be mapped to a single
      Serial Bus channel nuber by means of separate group address
      descriptors. The speed field specifies the aximum 1394 speed at which
      any of the senders within the multicast group transmits data. The
      expiration field specifies a future tie when the CAM will deallocate
      the channel nuber.
      
      No ore than ten seconds shall elapse from the transmission of the most
      recent advertiseent before the CAM initiates transmission of the
      subsequent advertiseent.
      
      5.2 Request for channel allocation
      
      Before any multicast transmission on other than the default channel
      nuber specified by the NETWORK_CHANNELS register, a sender within a
      multicast group shall insure that the CAM has allocated a channel
      nuber.
      
      A multicast sender should first listen for an MCAP advertisement. If the
      multicast group address is already mapped to a channel number, the
      sender need not ake a channel allocation request and may use the
      advertised channel nuber for multicast transmission.
      
      Otherwise the intended multicast sender shall transmit an MCAP message
      with an opcode of one which contains one or ore group address
      descriptors. Within each group address descriptor the group_address
      field shall specify the multicast group address for which a channel
      nuber is requested. If the requester has reasons to prefer a particular
      channel nuber, this may be specified as a hint in the channel field but
      the CAM is not obligated to allocate that channel. The intended
      multicast sender shall also specify, for each multicast group address,
      the aximum speed at which it intends to transmit data and the
      expiration tie for the channel allocation.
      
      
      
      
      Expires: October, 1998                                          [Page 8]


      Internet-Draft 00              1394 MCAP                     April 1998
      
      
      When the CAM receives an MCAP request for channel allocation(s), it
      shall attept to allocate a channel number in accordance with its own
      policies and the availability of Serial Bus channel nuber(s).
      
      If a channel is already allocated for the specified group_address, the
      CAM shall take no additional action other than to confir the channel
      nuber mapping in the next MCAP advertisement. If the channel number
      hint in the allocation request differs fro the channel number actually
      allocated, the CAM should transit an advertisement as soon as possible.
      Otherwise the advertiseent should be transmitted at the next scheduled
      tie.
      
      If no channel is allocated for the specified group_address, the CAM
      shall select a channel nuber and attempt to allocate it from the
      isochronous resource anager's CHANNELS_AVAILABLE register. The
      selection criteria shall be based upon the channel hint supplied in the
      request and the CAM's own policies; a value of 0xFF for channel
      indicates that the requester has provided no hint. If the chosen channel
      nuber is unavailable, the CAM may attempt to allocate a different
      channel nuber from CHANNELS_AVAILABLE. The retry algorithms are subject
      to policies iplemented by the CAM (e.g., some implementations might not
      allocate the last available channel but elect to aggregate multicast
      group addresses to already allocated channel(s)).
      
      When the CAM successfully allocates a channel nuber or assigns the
      multicast group address to an already allocated channel number, the new
      apping from multicast group address to channel number shall be
      advertised as soon as possible. The MCAP advertiseent constitutes a
      response to the channel allocation request and perits the multicast
      sender to comence transmissions.
      
      Otherwise, the CAM shall transit an error response as described below.
      
      5.3 Error response to channel allocation
      
      The CAM shall transit an MCAP error response message whenever one or
      ore multicast group addresses specified in an MCAP channel allocation
      request essage have not been mapped to other than the default multicast
      channel nuber.
      
      Multicast channel allocation ay fail because no channel numbers are
      available or because CAM policy prevents the allocation. For whatever
      reason, the MCAP error response essage shall contain a group address
      descriptor for each failure. The group_address field shall identify the
      multicast group and the status field shall contain a code that indicates
      the nature of the error. All other fields within the group address
      descriptor shall be ignored.
      
      5.4 Release of unneeded channel(s)
      
      When a multicast sender intends to cease transmissions for a multicast
      group that is not apped to the default multicast channel, it may notify
      the CAM by eans of an MCAP release message. The usage of the release
      
      
      
      Expires: October, 1998                                          [Page 9]


      Internet-Draft 00              1394 MCAP                     April 1998
      
      
      essage is optional, since the CAM will automatically deallocate the
      channel nuber when its expiration time is reached.
      
      An MCAP release essage has an opcode value of three and contains one or
      ore group address descriptors. Each descriptor identifies the
      group_address whose channel nuber is to be released. The expiration
      field shall specify a tie at least 30 seconds in the future for the
      release of the channel nuber. All other fields within the group address
      descriptor shall be ignored.
      
      In response to an MCAP release essage that identifies a group_address
      in the current channel ap, the CAM shall update the expiration time for
      the channel with the value of expiration and shall transit an MCAP
      advertiseent message as soon as possible. The advertisement that
      reflects the updated expiration tie is the response expected by the
      sender of the MCAP release essage.
      
      Whether multicast senders utilize the optional MCAP release message or
      not, channel allocations eventually expire for unused channel nubers.
      When the expiration tie associated with a particular multicast group
      and associated channel is reached (as easured by the CAM's CYCLE_TIME
      register), the CAM shall reove the multicast group and channel number
      fro the current channel map. Once the CAM has transmitted an MCAP
      advertiseent message in which no group descriptors reference a
      previously allocated channel nuber, the CAM shall deallocate the
      channel nuber in the isochronous resource manager's CHANNELS_AVAILABLE
      register.
      
      5.5 Solicitation of the channel ap
      
      Multicast recipients or senders ay request the CAM to advertise the
      channel ap by transmitting an MCAP solicitation request. No group
      address descriptors are included with this essage; the opcode value of
      five requests the CAM identified by bus_ID to advertise the channel ap.
      
      Originators of MCAP solicitation requests shall liit the rate at which
      they are transitted. Subsequent to sending a solicitation request,
      neither the originator nor any other node that observes the request
      shall send another MCAP solicitation request until either a) 10 seconds
      have expired or b) an MCAP advertiseent has been observed.
      
      The CAM should transit an MCAP advertisement message as soon as
      possible in response to the solicitation request.
      
      5.6 Periodic refresh of channel allocation(s)
      
      As described in 5.4 above, the CAM shall reove expired multicast group
      address and channel nuber pairs from the current channel map and
      ultiately return channel number(s) to the CHANNELS_AVAILABLE pool when
      no longer used by any multicast group.
      
      In order to prevent this occurrence for active multicast groups, at
      least one sender within a multicast group shall periodically extend the
      expiration tie for the channel map by means of an MCAP channel
      
      
      Expires: October, 1998                                         [Page 10]


      Internet-Draft 00              1394 MCAP                     April 1998
      
      
      allocation request essage (see 5.1). Although the CAM does not allocate
      a new channel, the request causes the expiration tie to be updated to a
      new future value. The frequency of MCAP channel allocation request
      essages and the expiration time specified in each should be coordinated
      such that at least three request essages are transmitted before the
      expiration tie specified by the earliest of the three is reached.
      
      In multicast groups where there is more than one sender it is desirable
      to liit the number of MCAP channel allocation request messages. The
      ideal situation is for one sender to generate the requests. If this
      sender intends to leave the multicast group, one of two events occur:
      either the sender transits the optional MCAP release message or it
      ceases transission of allocation request messages. In the first case,
      one of the other senders within the multicast group is expected to
      observe the release essage and initiate its own transmission of MCAP
      channel allocation request essages. Otherwise, if the time remaining
      before channel expiration falls below two seconds, that sender should
      initiate its own transission of MCAP channel allocation request
      essages. In the latter case, the allocation request shall be
      transitted at least one second before the expiration time.
      
      6. SECURITY CONSIDERATIONS
      
      This docuent specifies the use of an unsecured link layer, Serial Bus,
      for the transport of IPv4 datagras. Serial Bus is vulnerable to denial
      of service attacks; it is also possible for devices to eavesdrop on data
      or present forged identities. Iplementers who utilize Serial Bus for
      IPv4 should consider appropriate counter-easures within application or
      other layers.
      
      7. ACKNOWLEDGEMENTS
      
      This docuent represents work in progress by the IP/1394 Working Group.
      The editor wishes to acknowledge the contributions ade by all the
      active participants, either on the reflector or at face-to-face
      eetings, which have advanced the technical content.
      
      8. REFERENCES
      
      [1] IEEE Std 1394-1995, Standard for a High Perforance Serial Bus
      
      [2] ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture
          for Microcoputer Buses
      
      [3] IEEE Project P1394a, Draft Standard for a High Perforance Serial
          Bus (Suppleent)
      
      [4] IEEE Project P1394b, Draft Standard for a High Perforance Serial
          Bus (Suppleent)
      
      
      
      
      
      
      
      Expires: October, 1998                                         [Page 11]


      Internet-Draft 00              1394 MCAP                     April 1998
      
      
      9. EDITOR’S ADDRESS
      
      Peter Johansson
      Congruent Software, Inc.
      3998 Whittle Avenue
      Oakland, CA  94602
      
      (510) 531-5472
      (510) 531-2942 FAX
      pjohansson@aol.co
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      Expires: October, 1998                                         [Page 12]
      

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/