[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                       G. White
INTERNET DRAFT                                     Bay Networks, Inc
Expires 26 February 1998

<draft-ietf-ipcdn-ip-over-mcns-00.txt>                26 August 1997



          Logical IP Subnetworks over MCNS Data Link Services

Status of this Memo

   This document is an Internet-Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet-Drafts draft documents are valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Work In Progress

   This memo is work in progress in support of the activities of the IP
   over Cable Data Networks (ipcdn) Working Group of the IETF.

Table of Contents

   1. ABSTRACT  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2. ACKNOWLEDGMENT  . . . . . . . . . . . . . . . . . . . . . . .  2
   3. CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . .  2
   4. INTRODUCTION  . . . . . . . . . . . . . . . . . . . . . . . .  3
   5. IP SUBNETWORK CONFIGURATION . . . . . . . . . . . . . . . . .  5
   5.1  Background  . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.2  LIS Configuration Requirements  . . . . . . . . . . . . . .  5
   5.3  LIS Router Additional Configuration . . . . . . . . . . . .  6
   6. IP PACKET FORMAT  . . . . . . . . . . . . . . . . . . . . . .  6
   7. IP BROADCAST ADDRESS  . . . . . . . . . . . . . . . . . . . .  7
   8. IP MULTICAST ADDRESS  . . . . . . . . . . . . . . . . . . . .  7
   9. IP INTEGRATED SERVICES SUPPORT  . . . . . . . . . . . . . . .  8
   10. FILTERING . . . .  . . . . . . . . . . . . . . . . . . . . .  9



White                                                          [Page 1]


DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997


   11  CM REQUIREMENTS .  . . . . . . . . . . . . . . . . . . . . .  9
   12. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   13. MIB SPECIFICATION  . . . . . . . . . . . . . . . . . . . . . 10
   14. OPEN ISSUES  . . . . . . . . . . . . . . . . . . . . . . . . 10
   15. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 10
   16. AUTHOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1. ABSTRACT

   This memo defines an initial application of IP and ARP in an MCNS
   Community Access Television (CATV) Residential Access Network
   environment where the cable system is used for bi-directional data
   transfer. The MCNS network provides a traditional Ethernet or 802.2
   link layer service between a cable system head end and the customer
   premises using the cable television system infrastructure.  This
   interface is available via IEEE 802.1D layer services to support IP
   residential access networking services.

   In this memo, the term Logical IP Subnetwork (LIS) is defined to
   apply to traditional IP over Ethernet operating over MCNS services.

   The recommendations in this draft rely on existing IETF standards for
   IP and ARP over Broadcast Ethernet networks.

2. ACKNOWLEDGMENT

   The author would like to thank the efforts of the MCNS working group
   and the efforts of the IETF ipcdn working group.  The basis of this
   document was shamelessly stolen from Mark Laubach's draft for IP over
   802.14. Wilson Sawyer of Bay Networks provided valuable early review
   of the document.

3. CONVENTIONS

   The following language conventions are used in the items of
   specification in this document:

   o   MUST, SHALL, or MANDATORY -- the item is an absolute requirement
       of the specification.

   o   SHOULD or RECOMMEND -- this item should generally be followed for
       all but exceptional circumstances.

   o   MAY or OPTIONAL -- the item is truly optional and may be followed
       or ignored according to the needs of the implementor.






White                                                          [Page 2]


DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997


4. INTRODUCTION

   The goal of this specification is to allow compatible and
   interoperable implementations of Logical IP Subnetworks over MCNS
   services [MCNS1->4], including the transmission of IP datagrams and
   Address Resolution Protocol (ARP) requests and replies.

   It refers only to an MCNS network based on a two way capable cable
   plant [MCNS4] in which  the cable system is used for data transport
   in both upstream and downstream directions.  MCNS networks using non
   cable system based return paths such as the telephone network are not
   considered.

   This memo specifies the default operational model which will always
   be available in IP over MCNS implementations. Subsequent memos will
   build upon and refine this model, however, in the absence or failure
   of those extensions, operations will default to the specifications
   contained in this memo. Consequently, this memo will not reference
   these other extensions.

   The MCNS subnetwork consists of a Cable Modem Termination System
   (CMTS) typically located at the cable system head end and one or more
   cable modems (CM).  The CMTS and each CM are MCNS entities. The CMTS
   is responsible for all aspects of packet processing, resource
   sharing, and management of the MCNS Media Access Control (MAC) and
   Physical (PHY) functions.  A cable modem is essentially a slave of
   the CMTS.

   The organization of the CMTS to each CM is a strict rooted hierarchy:
   i.e., it is a two-level tree where the CMTS is the root and CM's are
   the children.  In the downstream direction, a MCNS MAC Protocol Data
   Unit (PDU) may be sent to an individual CM (unicast) or a group of
   CM's (multicast and broadcast).  In the upstream direction, all MAC
   PDUs (individual or group addressed) are sent from the CM to the
   CMTS.

   The CMTS is active and originates and terminates all upstream MAC PDU
   flows; that is, the CMTS processes the MAC PDUs and does not merely
   repeat upstream MAC PDUs back on the downstream for station to
   station communication.  The CMTS MAC layer service function
   determines whether information will be forwarded back on the
   downstream as defined in [MCNS4].  This may be based on data-link-
   layer (bridging) semantics, network-layer (routing) semantics or some
   combination of the two.

   The specific format of the MCNS MAC PDU is transparent to higher
   level services, e.g. IP datagrams, and therefore not of specific
   interest to this draft. However, it is useful to note that MCNS CMTS



White                                                          [Page 3]


DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997


   and CM entities support a variable length MAC PDU which encapsulates
   an Ethernet frame for transmission on the CATV network.  The MCNS MAC
   PDU is not presented to the IP layer.  For the purposes of protocol
   specification, IP may only access MCNS services via the 802.2 (LLC) /
   802.1D (bridge) MAC frame interface, hereafter called the Ethernet
   interface or Ethernet frame interface.

   Note: the MCNS Ethernet interface provides

   1) A frame based packet interface for the transmission of IP
   datagrams and ARP packets via the MCNS link services.

   2) An emulated Ethernet service between all CM's and the CMTS.

   3) Subject to CMTS forwarding rules a bridged Ethernet service
   between all CM's.

   The MCNS system employs a link layer encryption mechanism to provide
   basic data privacy.  This is transparent to higher layer services.

   Basic traffic management support and Quality of Service (QoS) support
   is provided by the MCNS system.  These mechanisms can be exploited to
   provide for IP integrated services support.

   The MCNS system specifications provide options to support
   IEEE802.1D/p, and IEEE802.1Q Virtual LAN (VLAN) extensions. These
   mechanisms may be used to facilitate support for IP integrated
   services.


   The characteristics for residential LISs using MCNS Ethernet frame
   service interface are:

   o   Supports default IP and ARP over Ethernet services.

   o   Other IETF standards can be used to extend these services; e.g.
       integrated services over 802.1D/p/Q.

   o   More than one LIS may be in operation over the same MCNS
       subnetwork (MAC domain) .

   o   An MCNS host system may be a member of more than one LIS.

   o   Layer management services are available to the frame service
       layer for the purposes of managing point-to-point services on the
       downstream and upstream, and point-to-multipoint services on the
       downstream.




White                                                          [Page 4]


DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997


   o   Layer management services are available to the frame service
       layer for traffic management and Quality of Service (QoS)
       control.


   The scope of this specification covers implementation,
   interoperability, and operational extension issues for delivering
   Logical IP Subnetwork services via a residential access network
   implemented via the MCNS standard.  Due to the flexibility provided
   by the MCNS system features, other IETF standards will be relied on
   when appropriate to do so.

   For the purposes of this memo, the MCNS subnetwork is intended to
   support residential Logical IP Subnetwork services.  This
   specification does not preclude the operation of other multiple non-
   IP services which may be in simultaneous service over the MCNS
   subnetwork: e.g., voice or video integrated services.

5. IP SUBNETWORK CONFIGURATION

 5.1 Background

   The MCNS subnetwork can support multiple simultaneously operating
   disjoint LISs over the same MAC domain. For each LIS a separate
   administrative entity configures its hosts and routers within the
   LIS. Each LIS operates and communicates independently of other LISs
   on the same MCNS network.

   In the classical model, hosts communicate directly via MCNS to other
   hosts within the same LIS using the appropriate address resolution
   service. In this case the ARP service is the mechanism for resolving
   target IP addresses to target 48-bit IEEE MAC addresses.

   As LISs are independent, inter-LIS protocol translation or address
   resolution conversion services are beyond the scope of this memo.
   Communication to hosts located outside of a LIS is provided via an IP
   router.

   The scope of an Ethernet LIS can span beyond an individual MCNS
   subnetwork using traditional frame-based bridging; e.g., IEEE 802.1D
   transparent bridging services.

 5.2 Residential LIS Configuration Requirements

   The requirements for IP members  (hosts, routers) operating in an
   MCNS-based LIS are:

   o   All members of the LIS MUST have the same IP network/subnet



White                                                          [Page 5]


DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997


       number and address mask [IP4].

   o   All members are directly connected
       to the MCNS subnetwork or to an IEEE 802.1 bridged network
       communicating with the MCNS subnetwork.

   o   All members of a LIS MUST use ARP as the mechanism for
       resolving IP addresses to link addresses.

   o   All LIS members connected to the MCNS subnetwork via an
       MCNS CM MUST be able to communicate via the MCNS
       subnetwork to or beyond the MCNS CMTS.
       The MCNS CMTS may be configured to not forward upstream
       communications from one station to another downstream station
       in the LIS; in this case, an IP router attached to or
       colocated with the CMTS should provide the forwarding from
       upstream to downstream.

   o   All LIS members connected to the MCNS subnetwork via an
       MCNS CMTS MUST be able to communicate via the MCNS
       subnetwork to or beyond any downstream MCNS station in the
       LIS.

   o   A LIS MAY span more than one MCNS subnetwork.
       Conventional Layer 2 bridging/switching MAY
       interconnect more than one CMTS.

 5.3 LIS Router Additional Configuration

   Routers providing LIS functionality over the MCNS subnetwork MAY also
   support the ability to interconnect multiple LISs.  Routers that wish
   to provide interconnection of differing LISs MUST be able to support
   multiple sets of parameters (one set for each connected LIS) and be
   able to associate each set of parameters to a specific IP
   network/subnet number. In addition, a router MAY be able to provide
   this multiple LIS support with a single physical MCNS interface with
   a different link address per LIS.

6. IP PACKET FORMAT

   Implementations built using the MCNS data link layer services MUST
   support IP over Ethernet as described in [IP1].  The MTU of this
   interface is 1500 octets.








White                                                          [Page 6]


DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997


7. IP BROADCAST ADDRESS

   The MCNS downstream MAC PDU supports point-to-multipoint addressing.
   For each LIS, the IP layer service support at the MCNS CMTS MUST
   create a single downstream point-to-multipoint group whose membership
   contains all MCNS CM's participating in that LIS.  By default, all
   downstream IP datagrams whose destination address specifies one of
   the four forms of IP broadcast addresses mited, directed, subnet
   directed, or all-subnets directed) [IP4] or an IP multicast address
   MUST be sent to members of the LIS using this MAC address group.

   Note: By default, all upstream IP datagrams are sent from the MCNS CM
   to the CMTS on the single point-to-point connection.

   Note: the above defaults do not preclude the use of additional
   downstream point-to-point or point-to-multipoint, or additional
   upstream point-to-point connections for handling of specific IP flows
   for integrated-services or multicast distribution support; e.g.,
   mapping IP flows to specific additional connections.

   In general, it is preferred that downstream data bandwidth resources
   be used in an efficient manner. Therefore, IP over MCNS
   implementations SHOULD only send one copy of a packet downstream per
   IP broadcast transmission or IP multicast transmission.




8. IP MULTICAST ADDRESS

   The MCNS downstream MAC service supports point-to-multipoint
   addressing.  MAC point-to-multipoint addresses can span LISs.

   For efficiency reasons, a separate point-to-multipoint group MAY be
   used to support downstream IP multicast datagram distribution. The
   specific implementation is beyond the scope of this memo, however it
   can be noted that single or multiple IP multicast groups MAY be
   mapped to a MAC point-to-multipoint group subject to the abilities of
   the MCNS CMTS and participating CM's.

   Note: By default, all upstream IP datagrams are sent from the MCNS CM
   to the CMTS on the single point-to-point connection.

   Note: the above defaults do not preclude the use of additional
   downstream point-to-multipoint or additional upstream point-to-point
   connections for handling of specific IP flows for integrated-services
   or multicast distribution support; e.g., mapping IP flows to specific
   additional connections.



White                                                          [Page 7]


DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997


   It is preferred that downstream data bandwidth resources be used in
   an efficient manner, therefore IP over MCNS implementations MUST only
   send one copy of a packet downstream per IP multicast transmission.
   Specially, MAC point-to-multipoint groups used for IP multicast
   datagram distribution may span LISs.

   For example, there may be two LISs operating via an MCNS subnetwork,
   LIS-1 and LIS-2.  LIS1 may have station members ST-A, ST- B, and ST-
   C. and LIS-2 may have station members ST-X, ST-Y, and ST-Z.  The
   Ethernet layer management services at the CMTS would have created two
   point-to-multipoint groups PTM-1 and PTM-2 used for default
   downstream broadcast and multicast transmission.  The membership of
   PTM-1 would be ST-A, ST-B, and ST-C.  The membership of PTM-2 would
   be ST-X, ST-Y, ST-Z.  There may be another point-to-multipoint group
   for distributing a specific IP multicast group, call this PTM-3.  The
   members of PTM-3 might be ST-B, ST-C, and ST-X therefore PTM-3 spans
   LIS-1 and LIS-2.

   The coupling of the MCNS layer management services responsible for
   group management with that of IP Internet Group Management Protocol
   (IGMP) is TBD.

9. IP INTEGRATED SERVICES SUPPORT

   By default, the MCNS service delivers IP traffic on a best effort
   basis.

   The underlying protocol of MCNS is designed to support multiple
   service classes with their associated Quality of Service requirements
   (maximum data rate, guaranteed data rate, priority) subject to the
   characteristics of the downstream and upstream channel rates.
   Mappings from IP integrated services to IP over MCNS can be exploited
   to provide traffic management and Quality of Service (QoS) on a per
   IP flow basis, for unicast and multicast traffic.  As such, these
   capabilities are available for the support of integrated services and
   RSVP over MCNS.

   The MCNS MAC protocol contains the concept of Service IDs which
   provide both device identification and quality-of-service management.
   A Service ID defines a particular mapping between a CM and the CMTS.
   This mapping is the basis on which bandwidth is allocated to the CM
   by the CMTS and hence by which quality of service is implemented.

   The CMTS MAY assign one or more Service IDs (SIDs) to each CM,
   corresponding to the classes of service required by the CM. This
   mapping MUST be negotiated between the CMTS and the CM during CM
   registration.




White                                                          [Page 8]


DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997


   In a basic CM implementation a single Service ID MAY be used to offer
   best-effort IP service. However, the Service ID concept allows for
   CMs to be developed with support for multiple service classes. This
   allows for a service ID to be provided for each "data flow" on which
   protocols such as RSVP and RTP are based.

   The mechanism to achieve this is TBD.

10. FILTERING

   The MCNS system provides for the use of filtering for IP and ARP
   protocol packets.  This filtering is available for use by the network
   operator or the end user (subject to the operator's policy).

   The MCNS system permits filters to be placed in the upstream and
   downstream at the CM and the CMTS and independently for point-to-
   point and point-to-multipoint connections.  In addition, filters may
   be placed at the CMTS in the service function responsible for
   forwarding packets from upstream to downstream.


11. CM REQUIREMENTS

   The IP over MCNS cable modem MUST be able to separately and
   simultaneously reassemble or reconstruct packets for each point-to-
   point or point-to-multipoint downstream connection being used for IP
   LIS or IP Multicast services.


   By default, all unicast, broadcast, and multicast communications from
   an IP over MCNS CM MUST be sent using the point-to-point connection
   to the MCNS CMTS.  It is noted that the default behavior MAY be
   modified in the future by providing additional connections for IP
   traffic from the CM to the CMTS.


12. SECURITY

   The MCNS system employs a DES based link security system between the
   CMTS and all CM's to protect the confidentiality of communications
   over the RF channels.  The specific mechanisms are beyond the scope
   of this memo, however it should be noted that

   1) the security system is transparent to any higher layer protocol
   (including IP).

   2) the security system does not preclude the use of IPSEC methods for
   providing additional security.



White                                                          [Page 9]


DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997


   3) each MAC point-to-point connection is managed using different keys
   making it difficult to snoop on another station's unicast MAC
   traffic.

   4) each MAC point-to-multipoint connection is managed using different
   keys (stations only have keys for the MAC multicast groups of which
   they are a member).

13. MIB SPECIFICATION

   TBD.

14. OPEN ISSUES


   o   IEEE 802.1D/p and Q extensions, including GARP will be mentioned
       in a future revision of this memo.

   o   RSVP coupling to MCNS service id is TBD.

   o   IGMP coupling to MCNS layer management is TBD.

15. REFERENCES


   [MCNS1] MCNS Data Over Cable Service Interface Specification
           Request for Proposals, December 11, 1995.

   [MCNS2] MCNS Cable Modem Termination System
           - Network-Side Interface Specification
           SP-CMTS-NSID04-960409 (CMTS-NSI), April 9, 1996.

   [MCNS3] MCNS Cable Modem to Customer Premise Equipment Interface
           Specification SP-CMCID04-960409 (CMCI), April 9, 1996

   [MCNS4] MCNS Radio Frequency Interface
           Specification SP-RFII01-970326, March 26, 1997


   [IP1] Hornig, C.., "A Standard for the Transmission for IP Datagrams
         over Ethernet Networks", RFC-894, Symbolics Cambridge Research
         Center, April, 1984.

   [IP2] Plummer, D., "An Ethernet Address Resolution Protocol - or -
         Converting Network Addresses to 48.bit Ethernet Address for
         Transmission on Ethernet Hardware",
         RFC-826, MIT, November 1982.




White                                                         [Page 10]


DRAFT          Logical IP Subnetworks over MCNS Services  26 August 1997


   [IP3] Postel, J., and Reynolds, J., "A Standard for the Transmission
         of IP Datagrams over IEEE 802 Networks", RFC-1042,
         USC/Information Sciences Institute, February 1988.

   [IP4] Braden, R., "Requirements for Internet Hosts -- Communication
         Layers", RFC-1122, USC/Information Sciences Institute, October
         1989.

   [IP5] Deering, S, "Host Extensions for IP Multicasting", RFC-1112,
         USC/Information Sciences Institute, August 1989.

16. AUTHOR

   Gerry White
   Broadband Technology Division
   Bay Networks, Inc.
   200 Bulfinch Drive
   Andover, MA 01810

   Phone: 508.692.1600
   FAX:   508.692.3200
   EMail: gwhite@baynetworks.com





























White                                                         [Page 11]