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]
