--- 1/draft-ietf-ipcdn-ipover-802d14-00.txt 2006-02-04 23:36:11.000000000 +0100 +++ 2/draft-ietf-ipcdn-ipover-802d14-01.txt 2006-02-04 23:36:11.000000000 +0100 @@ -1,16 +1,15 @@ Network Working Group Mark Laubach INTERNET DRAFT Com21, Inc. -Expires 21 February 1998 - 21 August 1997 -Obsoletes: +Expires 13 September 1998 + 13 March 1998 Logical IP Subnetworks over IEEE 802.14 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. @@ -31,27 +30,26 @@ over Cable Data Networks (ipcdn) Working Group of the IETF. The IEEE 802.14 working group has reached a layer of stability necessary for the activities the IETF ipcdn working group. This draft should be considered as the initial work that will be updated over time in concert with IEEE 802.14 development. This memo will track IEEE 802.14 progress with the goal of being complete when the IEEE 802.14 work reaches sponsor ballot in the IEEE standards process. The IEEE 802.14 Cable-TV Access Method And Physical Layer Specification is work in progress in the IEEE 802 LAN/MAN standards - committee. At the time of this draft, the IEEE 802.14 will be - released for internal working group review and comment ballot based - on the Draft2 Revision 2 specification released from the July 1997 - IEEE 802.14 working group meeting. Comments on Draft2 Revision2 will - be due by the September 1997 IEEE 802.14 interim meeting. + committee. At the time of this draft, the IEEE 802.14 is planning + the release of its next comment ballot for July 1998. In the + previous ballot process, variable length (Ethernet) mode was removed + so as to differentiate the services from MCNS DOCSIS. -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 Table of Contents 1. ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. ACKNOWLEDGMENT . . . . . . . . . . . . . . . . . . . . . . . 2 3. CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 3 5. IP SUBNETWORK CONFIGURATION . . . . . . . . . . . . . . . . . 6 5.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2 LIS Configuration Requirements . . . . . . . . . . . . . . 6 @@ -88,21 +86,21 @@ IP and ARP over Broadcast Ethernet networks. The tree-based hierarchic nature of the IEEE 802.14 MAC subnetwork permits convenient extensions to Classical IPOA model for broadcast and multicast in the downstream direction of the CATV plant. 2. ACKNOWLEDGMENT The author would like to thank the efforts of the IEEE 802.14 working group and the efforts of the IETF ipcdn working group. Randy Frei -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 from Com21 provided early review of this memo and contributed to the open issues list. 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 @@ -139,47 +137,34 @@ The organization of the HC to each station is a strict rooted hierarchy: i.e., it is a two-level tree where the HC is the root and stations are the children. In the downstream direction, a 802.14 MAC Protocol Data Unit (PDU) may be sent to an individual station (unicast) or a group of stations (multicast and broadcast). In the upstream direction, all MAC PDUs (individual or group addressed) are sent from the station to the HC. The HC is active and originates and terminates all upstream MAC PDU flows; that is, the HC processes the MAC PDUs and does not merely repeat upstream MAC PDUs back on the -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 downstream for station to station communication. The HC MAC layer service function determines whether information will be forwarded back on the downstream; e.g. similar to Ethernet bridge forwarding behavior. The specific format of the IEEE 802.14 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 - IEEE 802.14 HC and ST entities support an ATM format MAC PDU mode by - default, with an optional variable length MAC PDU mode. The choice - of MAC PDU is vendor and then operator specified. The IEEE 802.14 MAC - PDU is not presented to the IP layer. For the purposes of protocol - specification, IP may only access IEEE 802.14 services via one or two - layer service interfaces: the ATM cell-based service interface or the - 802.2 (LLC) / 802.1D (bridge) MAC frame interface, hereafter called - the Ethernet interface or Ethernet frame interface. The selection of - ATM cell MAC PDU mode or variable MAC PDU mode transparent to the - Ethernet frame interface. - - Note: the term Ethernet interface is meant to convey that a frame - based packet interface exists for the transmission of IP datagrams - and ARP packets via the IEEE 802.14 link services. The use of this - term does not imply at this time that IEEE 802.14 provides an - emulated Ethernet service between all stations, and between all - stations and the HC. + IEEE 802.14 HC and ST entities support an ATM format MAC PDU mode. + The IEEE 802.14 MAC PDU is not presented to the IP layer. For the + purposes of protocol specification, IP may only access IEEE 802.14 + services via its ATM cell-based service interface The IEEE 802.14 system employs a DES based link security system between the HC and all stations 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 (i.e. IP, ATM, MPEG), 2) the security system does not preclude the use of IPSEC methods for providing additional security for residential IP, 3) each MAC point-to-point connection is managed using different keys making it difficult to snoop on another station's unicast MAC @@ -190,72 +175,48 @@ The IEEE 802.14 system enables comprehensive traffic management support and Quality of Service (QoS) support for ATM networking purpose. As such, these mechanisms can be exploited to provide for IP integrated services support. The IEEE 802.14 system will provide support of IEEE802.1D/p, with future support for IEEE802.1/Q Virtual LAN (VLAN) extensions. As such, these mechanisms can be exploited for IP integrated services support. -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 - The characteristics for residential LISs using IEEE 802.14 ATM cell- based service interface are: o RFC1577, RFC1626, and RFC1755 provide default IP over ATM LIS services. o Other IETF standards can be used to extend these services; e..g MARS, integrated services over ATM, etc. o More than one LIS may be in operation over the same 802.14 subnetwork (MAC domain) . +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 + o An IEEE 802.14 station may be a member of more than one LIS. o Layer management services are available to the ATM layer for the purposes of managing point-to-point services on the downstream and upstream, and point-to-multipoint services on the downstream. o Layer management services are available to the ATM layer for traffic management and Quality of Service (QoS) control. o An IP router/gateway function may be colocated at the HC, e.g. in the case of an IEEE 802.14 "port card" in an IP router; or the router/gateway may be connected via an ATM network to the HC. This specification will not preclude either scenario. - The characteristics for residential LISs using IEEE 802.14 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 802.14 - subnetwork (MAC domain) . - - o An IEEE 802.14 station 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. - - o Layer management services are available to the frame service - layer for traffic management and Quality of Service (QoS) - control. - -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 - 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 IEEE 802.14 standard. Due to the flexibility provided by the IEEE 802.14 system features, other IETF standards will be relied on when appropriate to do so. For example the ATM nature of the IEEE 802.14 system suggests that the existing IETF classical IP over ATM family of specifications will apply in general, with specific differences outlined in this memo for reasons of operational efficiency or general IP over Cable Data Network issues. @@ -277,50 +238,46 @@ other LISs on the same IEEE 802.14 network. In the classical model, hosts communicate directly via IEEE 802.14 to other hosts within the same LIS using the appropriate address resolution service. In the case of the Ethernet frame service, the ARP service is the mechanism for resolving target IP addresses to target 48-bit IEEE MAC addresses. In the case of the ATM service, the ATMARP service is the mechanism for resolving target IP addresses to target ATM endpoint addresses. +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 + 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 IEEE 802.14 subnetwork using traditional frame-based bridging; e.g., IEEE 802.1D transparent bridging services. The scope of an ATM LIS can span beyond an individual IEEE 802.14 subnetwork using conventional ATM networking. -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 - 5.2 Residential LIS Configuration Requirements The requirements for IP members (hosts, routers) operating in an IEEE 802.14-based LIS are: o All members of the LIS MUST have the same IP network/subnet number and address mask [8]. o All members within a ATM cell-based LIS are directly connected to the IEEE 802.14 subnetwork or to an ATM network connected to the IEEE 802.14 subnetwork. - o All members within an Ethernet based LIS are directly connected - to the IEEE 802.14 subnetwork or to an IEEE 802.1 bridged network - communicating with the IEEE 802.14 subnetwork. - o All members of a LIS MUST have a mechanism for resolving IP addresses to link addresses (ARP or ATMARP). o All members of a LIS MUST have a mechanism for resolving link addresses to IP addresses via an inverse address resolution protocol (InARP or InATMARP). o All LIS members connected to the IEEE 802.14 subnetwork via an IEEE 802.14 station MUST be able to communicate via the IEEE 802.14 subnetwork to or beyond the IEEE 802.14 HC. By default, @@ -332,40 +289,35 @@ o All LIS members connected to the IEEE 802.14 subnetwork via an IEEE 802.14 HC MUST be able to communicate via the IEEE 802.14 subnetwork to or beyond any downstream IEEE 802.14 station in the LIS. o A LIS MAY span more than one IEEE 802.14 subnetwork. In the case of frame based, conventional Layer 2 bridging/switching MAY interconnect more than one HC. In the case of ATM based, a backend ATM network MAY interconnect more than one HC. +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 + 5.3 LIS Router Additional Configuration Routers providing LIS functionality over the IEEE 802.14 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 - -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 - network/subnet number. In addition, a router MAY be able to provide this multiple LIS support with a single physical IEEE802.14 interface with a different link address per LIS. 6. IP PACKET FORMAT - Implementations built using the IEEE 802.14 Ethernet frame layer - services MUST support IP over Ethernet as described in [21]. The MTU - of this interface is 1500 octets. - Implementations built using the IEEE 802.14 ATM cell based layer services MUST support IEEE 802.2 LLC/SNAP encapsulation as described in [2]. LLC/SNAP encapsulation is the default packet format for IP datagrams running via IP over ATM networks. The default MTU of this interface is 9180 octets. This memo recognizes that end-to-end signaling within ATM may allow negotiation of encapsulation method or MTU on a per-VC basis. 7. IP BROADCAST ADDRESS @@ -386,21 +338,21 @@ 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 IEEE802.14 implementations SHOULD only send one copy of a packet downstream per IP broadcast transmission or IP multicast transmission. -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 8. IP MULTICAST ADDRESS The IEEE 802.14 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 @@ -416,54 +368,54 @@ or multicast distribution support; e.g., mapping IP flows to specific additional connections. It is preferred that downstream data bandwidth resources be used in an efficient manner, therefore IP over IEEE 802.14 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 IEEE 802.14 - 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 HC 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. + 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 HC 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 IEEE 802.14 layer management services responsible for group management with that of IP Internet Group Management Protocol (IGMP) is TBD. 9. IP INTEGRATED SERVICES SPPORT By default, the IEEE 802.14 service delivers IP traffic on a best effort basis. -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 The underlying protocol of IEEE 802.14 is designed to support the ATM service classes: Constant Bit Rate (CBR), real-time Variable Bit Rate (rt-VBR), non-real-time Variable Bit Rate (nrt-VBR), Available Bit Rate (ABR), and Unspecified Bit Rate (UBR), and their associated Quality of Service requirements (delay, delay tolerance, cell loss rate) subject to the characteristics of the downstream and upstream channel rates. Mappings from IP integrated services to IP over ATM 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 ATM cell-based access as - well as Ethernet frame mode access. Specifications for the support - of integrated services and RSVP over IEEE 802.14 are TBD. + such, these capabilities are available for ATM cell-based access + Specifications for the support of integrated services and RSVP over + IEEE 802.14 are TBD. 10. FILTERING The IEEE 802.14 system does not preclude the use of filtering for IP and ARP protocol packets. Such filtering is TBD. The IEEE 802.14 system permits filters to be placed in the upstream and downstream at the ST and the HC and independently for point-to- point and point-to-multipoint connections. In addition, filters may be placed at the HC in the service function responsible for @@ -483,46 +435,43 @@ behavior MAY be modified in the future by providing additional connections for IP traffic from the IEEE 802.14 station to the IEEE 802.14 HC. Specifications for optional LIS forwarding requirements are TBD. 12. SECURITY TBD. -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 13. MIB SPECIFICATION The IEEE 802.14 MIB is TBD. 14. OPEN ISSUES o ATM signaling support by IEEE 802.14 and specific HC functionality in support of IP will be mentioned in a future revision of this memo. o IEEE 802.1D/p and Q extensions, including GARP will be mentioned in a future revision of this memo. o RSVP coupling to IEEE 802.14 layer management is TBD. o IGMP coupling to IEEE 802.14 layer management is TBD. o IETF Integrated Services support by IEEE 802.14 is TBD. - o It is ambiguous about whether IP members must be connected via - ATM mode or Ethernet mode. 802.14 will support either mode. - Also, whether a mixture of 802.14 capable LIS members and - bridged/switched connected LIS members is allowed on a HC or all - stations must be of one type or the other. + o May need to add comments about IP over Ethernet/RFC1483 + implementations. o The HC forwarding option results in routing intra-LIS. What about subnet-directed broadcasts (blocked)? ARPs? Will the headend proxy ARP for all stations? If the stations are members of the same LIS, then they will try to talk directly and their packets will have to be forced to the router (in frame mode, have the headend proxy ARP for with the router's MAC for any LIS members that are not local to that station). What about ATMARP issues? ICMP redirects should be disabled from the router. Are we assuming that members of an LIS may just be under the same @@ -534,24 +483,24 @@ router will be routed back to the destination station, but multicast assumes all stations can hear each other? Without a specific broadcast facility upstream, do we have to build one for multicast: receive multicast group membership, facilitate group access control and forward multicast back downstream based on this info? Or does 802.14 address this? For ATM mode would something like MARS be needed? What about NHRP (as opposed to ATM ARP)? -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 - From Scott Brim: +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 + The head end needs to be intelligent enough to do various filtering at the PDU (not cell) level. Regardless of whether it's used the code needs to be in there. This brings up two questions -- tell me if I read it right: * doesn't forwarding cells to the outside world (beyond the head end) conflict with having frame-level intelligence? That is, does the head end have to accumulate cells and reassemble frames even if it's forwarding cells to the outside world (under any conditions)? @@ -582,26 +531,26 @@ [5] 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. [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, Geneva, 19-29 January 1993. [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September - 2 October 1992. -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 - [8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC-1122, USC/Information Sciences Institute, October 1989. +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 + [9] ATM Forum, "ATM User-Network Interface (UNI) Specification Version 3.1.", ISBN 0-13-393828-X, Prentice-Hall, Inc., Upper Saddle River, NJ, 07458, September, 1994. [10] Deering, S, "Host Extensions for IP Multicasting", RFC-1112, USC/Information Sciences Institute, August 1989. [11] Colella, Richard, and Gardner, Ella, and Callon, Ross, "Guidelines for OSI NSAP Allocation in the Internet", RFC-1237, USC/Information Sciences Institute, July 1991. @@ -631,26 +580,26 @@ Managed Objects for Classical IP and ARP over ATM Using SMIv2", IETF, draft-ietf-ipatm-mib-01 (work in progress), February, 1996. [19] ATM Forum, "ATM User-Network Interface (UNI) Specification Version 4.0", ATM Forum specification afsig-0061.000, ftp://ftp.atmforum.com/, July, 1996. [20] IEEE 802 LAN/MAN, "IEEE 802.14 Draft 2 Revision 2", IEEE 802.14 Working Group work in progress, July, 1997. -DRAFT Logical IP Subnetworks over IEEE 802.14 Services August 1997 - [21] Hornig, C.., "A Standard for the Transmission for IP Datagrams over Ethernet Networks", RFC-894, Symbolics Cambridge Research Center, April, 1984. +DRAFT Logical IP Subnetworks over IEEE 802.14 Services March 1998 + 16. AUTHOR Mark Laubach Com21, Inc. 750 Tasman Drive Milpitas, CA 95035 Phone: 408.953.9175 FAX: 408.953.9299 EMail: laubach@com21.com