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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/