omniran-13-0032-03-0000 1 ieee 802 scope of omniran date: 2013-05-13 authors:...
TRANSCRIPT
omniran-13-0032-03-0000
1
IEEE 802 Scope of OmniRANDate: 2013-05-13
Authors:Name Affiliation Phone Email
Max Riegel NSN +49 173 293 8240 [email protected]
Notice:This document does not represent the agreed view of the OmniRAN EC SG. It represents only the views of the participants listed in the ‘Authors:’ field above. It is offered as a basis for discussion. It is not binding on the contributor, who reserve the right to add, amend or withdraw material contained herein.
Copyright policy:The contributor is familiar with the IEEE-SA Copyright Policy <http://standards.ieee.org/IPR/copyrightpolicy.html>.
Patent policy:The contributor is familiar with the IEEE-SA Patent Policy and Procedures:<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and <http://standards.ieee.org/guides/opman/sect6.html#6.3>.
Abstract
Access networks comprise functions which extend beyond the scope of IEEE 802.The contribution provides different architectural views on access networks to define the functional pieces of access networks which fall into the scope of IEEE 802.
omniran-13-0032-03-0000
2
IEEE 802 Scope of OmniRAN
Architectural models and functional views of OmniRAN in
the scope of IEEE 802
omniran-13-0032-03-0000
3
MOTIVATIONIEEE 802 Scope of OmniRAN
omniran-13-0032-03-0000
4
How and where does OmniRAN fit?(Informative figure IEEE 802-2001)
• OmniRAN comprises the functions of access networks based on IEEE 802 technologies• As IEEE 802 access networks consist of the cooperation of multiple instances of IEEE 802
technologies with a single higher layer control and traffic forwarding function, there is no obvious place for OmniRAN in the IEEE 802-2001 informative figure.– Like for other IEEE 802 standards, e.g. IEEE 802.21, IEEE 802.1X, …
omniran-13-0032-03-0000
5
Really helpful to describe and define OmniRAN scope within IEEE 802?
• The amended figure 5 of 802rev-D1.6 puts OmniRAN into a single box of the higher layer end-point stack aside of the data path– discussed in the Mar ‘13 Orlando session
• The figure may not be completely wrong, however it provides not much guidance on which functional pieces are in scope of OmniRAN and their relation to IP based protocols.
OmniRAN
R2, R
3 R4
omniran-13-0032-03-0000
6
ACCESS NETWORK ARCHITECTURAL VIEWS
IEEE 802 Scope of OmniRAN
omniran-13-0032-03-0000
7
OmniRAN architecture partitioning fordynamic attachment of terminals to networks
• Communication networks supporting dynamic attachment of terminals are usually structured into– Access Network
• Distributed infrastructure for aggregation of multiple network access interfaces into a common interface
– Core Network• Infrastructure for control and management of network access and end-to-end IP
connectivity
– Services• Infrastructure for providing services on top of established IP connectivity
Internet
Terminal Access Network ServicesCoreNetwork
omniran-13-0032-03-0000
8
Functions for establishment of end-to-end Connectivity
Access Network
• Network advertisement• Pre-association signalling• IEEE 802.xx PHY and MAC• Authentication, authorization and
accounting client• L2 session establishment
– w/ QoS and Policy Enforcement
• L2 mobility management inside and across access networks
• Mobility Gateway• Traffic forwarding to core based
on L2 addresses
Core Network
• Authentication, authorization and accounting server
• IP address management • Policy & QoS management
based on a SLA• Mobility among multiple
access networks• IP connectivity establishment
to Internet and services• Roaming via other core
networks
omniran-13-0032-03-0000
9Medium Medium
Access Network Architectual Views
Data Link
Physical
Network
Transport
Application
Data LinkPhysical
Access Network Terminal
Data LinkPhysical
Data Link
Physical
Network
Transport
Application
NetworkNetwork
Medium Medium
Core Service
Data LinkPhysical
Data LinkPhysical
Data Link
Physical
Data Link
Physical
R2
R1 R3 R5
ScanningNetwork Selection
AssociationAuthentication
Host ConfigurationApplication
Layered Protocol View
Procedural View
Topology View
omniran-13-0032-03-0000
10
Topology view on OmniRAN architecture and reference points
Access Core
InternetR1 R3
R4
Access Core
Internet
R3
R5
Terminal
R3Authentication
Authorization
Accounting
Location
CoA
Mobility
Encapsulation
Authentication
Authorization
Accounting
Location
CoA
Mobility
EncapsulationDataPath
Access Core
Transport
• Reference Points represent a bundle of protocols between peer entities- Similar to real network interfaces
R2
Access
R3
omniran-13-0032-03-0000
11
The benefits of the topology view:Reference points
• Reference points denote the interconnections between functional entities in the access network, e.g.– R1 between terminal and base station:
• Access link, technology specific
– R2 between terminal and core network:• User & terminal authentication, subscription & terminal management
– R3 between access network and core network:• Authorization, service management, user data connection, mobility support, accounting,
location
– R4 between access networks:• Inter-access network coordination and cooperation, fast inter-technology handover
– R5 between core networks: • Inter-operator roaming control interface
• Reference points build an excellent foundation for realizing interoperability between real world network equipment.
• However reference points usually do not reflect nor match the scope of IEEE 802.
omniran-13-0032-03-0000
12
Accounting
Disassociation
Host Configuration
Application
Policy Control
Application
Host Config Release
Accounting
AuthenticationAuthorization
Association
Network Selection
Scanning
Procedural view on OmniRAN
AAA DHCP ApplicationANQP
L2 ProtocolL2 Attributes
L3+ ProtocolL2 Attributes
L3+ ProtocolL3+ Attributes
Legend: L2 ProtocolL3+ Attributes
omniran-13-0032-03-0000
13
The benefit of the procedural view:Getting insights into protocols
• Scanning: Finding out about the existence of potential communication peers– Scope of individual IEEE 802.xx specifications
• Network selection: Finding the most appropriate network access– IEEE 802.xx protocol for higher layer information
• Association: Setting up the access link– Scope of individual IEEE 802.xx specifications
• Authentication– Security framework, based on IEEE 802.1X
• Authorization: Setting up the IEEE 802 communication link– Attributes and functions depending on particular IEEE 802.xx technologies
• Accounting: Usage and inventory reporting– Attributes depending on particular IEEE 802.xx technologies
• Policy Control: Adjustment of the user data connection– Attributes depending on particular IEEE 802.xx technologies
• Host Configuration: Getting the IP communication parameters– IP protocol for IP configuration parameters
• Application: Making productive use of the communication infrastructure– IP protocol for application parameters
• Host Config Release: Releasing the IP communication parameters– IP protocol for IP configuration parameters
• Disassociation: Releasing the access link– Scope of individual IEEE 802.xx specifications
omniran-13-0032-03-0000
14
Current scope of IEEE 802
Medium Medium Medium
The benefit of the layered protocol view:Detailed representation of the data path
• IEEE 802 is dealing with packet transport functions in the Data Link and Physical layers.
• More fine-grain layering models are used by IEEE 802 to describe the architecture of its work.
Data Link
Physical
Network
Transport
Application
Data Link
Physical
Network
Transport
Application
Data Link
Physical
Data Link
Physical
Data Link
Physical
Data Link
Physical
Access Network Terminal Core
omniran-13-0032-03-0000
15
IEEE 802 ARCHITECTUREIEEE 802 Scope of OmniRAN
omniran-13-0032-03-0000
16
IEEE 802 Reference Model for End-Stations(802rev-D1.6)
Reference Model within the 7 layer ISO-OSI model
• IEEE 802 provides link layer connectivity to the overall communication architecture
• It covers the Physical and the Data link layer of the ISO-OSI 7 layer model
• Data link layer is represented in IEEE 802 by MAC and LLC sub-layers
• Functionality above Data link layer is considered as ‘higher layer’.
Reference Model exposing specific IEEE 802 functions
• The IEEE 802 connectivity stack is supplemented by a management plane and a plane representing IEEE 802.21 MIH.
• MIH comprises a number of control SAPs into each of the layer of the IEEE 802 reference model
• The network management model of IEEE 802 is aligned with the ITU TMN framework and provides the definition of managed objects for each of the layers of the IEEE 802 architecture
• IEEE 802 allows for special purpose network management protocols when the usual network management approach with managed objects is not sufficient.
omniran-13-0032-03-0000
17
IEEE 802 Reference Model for Bridges
• IEEE 802 provides a bridging model for interconnection of multiple network segments based on data link layer functionality
• Different bridging protocols can handle the issues of various topologies including avoidance of data loops and establishment of ‘optimized’ filtering and forwarding decisions.
• Bridging protocols have been extended to cope with multiple operational domains of an hierarchical provider structure.
omniran-13-0032-03-0000
18
OMNIRAN ARCHITECTURE WITHIN SCOPE OF IEEE 802
IEEE 802 Scope of OmniRAN
omniran-13-0032-03-0000
19
Current scope of IEEE 802
Medium Medium Medium
OmniRAN Reference Points in the layered protocol view
• OmniRAN reference points describe interfaces into IEEE 802 network functions.– Most of the Reference Points mainly comprise signaling information.
• Signaling information configures functionalities in the PHY and DataLink layer of IEEE 802 functions.
• The signaling information is carried by IP protocols from a central database server to the IEEE 802 functions– Similar to the definition and processing of network management information in IEEE 802
• Effectively each of IEEE 802 network elements contains an IP communication stack on top of the IEEE 802 data path for the exchange of the control information.
Data Link
Physical
Network
Transport
Application
Data Link
Physical
Network
Transport
Application
Data Link
Physical
Data Link
Physical
Data Link
Physical
Data Link
Physical
Network
Transport
Application
Network
Transport
Application
omniran-13-0032-03-0000
20
Current scope of IEEE 802
Medium Medium Medium
Mapping of OmniRAN Reference Points to IEEE 802 Reference Model
• R1, R2, R3 Reference Points can be mapped onto the IEEE 802 Reference Model– R1 represents the PHY and MAC layer functions between terminal and base station
• Completely covered by IEEE 802 specifications
– R2 represents the L2 control protocol functions between terminal and central entities for control and AAA.
– R3 represents the L1 & L2 control interface from a central control entity into the network elements
– ‘R2’ and ‘R3 Control’ may comprise only definitions of attributes• However IP based protocols to carry control information elements are out of scope of IEEE 802
– ‘R3 Data’ may define a special kind of Data Link SAP
Data Link
Physical
Higher Layers
Data Link
Physical
Data Link
Physical
Data Link
Physical
Data Link
Physical
Data Link
Physical
Higher Layers Control Higher Layers Control
Higher Layers
R3 DataR3 ControlR2/R3 Control
R1
omniran-13-0032-03-0000
21
Further considerations
• Key issue is the handling of IEEE 802 specific attributes of IP protocols within the activities of IEEE P802
• IEEE P802 has an established routine for defining the MIBs of IEEE 802 technologies– Partly done by itself and partly within the IETF
• Processes for defining other IEEE 802 related attributes in IETF vary depending of protocol– e.g. AAA attributes are mainly done by IETF with some informal
review by IEEE 802 WGs• Cooperation between IEEE 802 and IETF is currently
reviewed and refined in [draft-iab-rfc4441rev-04.txt]– More details on next slide.
omniran-13-0032-03-0000
22
[draft-iab-rfc4441rev-04.txt]Appendix A. Current examples of IEEE 802 and IETF
Work Item Collaboration
A.1. MIB Review
Historically the MIB modules for IEEE 802.1 and IEEE 802.3 were developed in the IETF Bridge MIB and Hub MIB Working Groups respectively. With travel budgets under pressure, it has become increasingly difficult for companies to fund employees to attend both IEEE 802 and IETF meetings. As a result, an alternative was found to past arrangements that involved chartering MIB work items within an IETF WG by transferring the work to IEEE 802 with expert support for MIB review from the IETF. In order to encourage wider review of MIBs developed by IEEE 802 WGs, it is recommended that MIB modules developed in IEEE 802 follow the MIB guidelines [RFC4181]. An IEEE 802 group may request assignment of a 'MIB Doctor' to assist in a MIB review by contacting the IETF Operations and Management Area Director. By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing the SNMP quality control process, the IETF and IEEE 802 seek to ensure quality while decreasing overhead. The process of transfer of the MIB work from the IETF Bridge MIB WG to IEEE 802.1 WG is documented in [RFC4663].
omniran-13-0032-03-0000
23
A.2. AAA Review
IEEE 802 WGs requiring new AAA applications should send a liaison request to the IETF. Where merely new attributes definitions are sufficient rather than defining a new authentication, authorization and accounting logic/procedures, an Internet-Draft can be submitted and review can be requested from AAA-related WGs such as the RADEXT or DIME WGs. For attributes of general utility, and particularly those useful in multiple potential applications, allocation from the IETF standard attribute space is preferred to creation of IEEE 802 Vendor-Specific Attributes (VSAs). As noted in [RFC3575]: "RADIUS defines a mechanism for Vendor-Specific extensions and the use of that should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful".
Where allocation of VSAs are required, it is recommended that IEEE 802 create a uniform format for all of IEEE 802, rather than having each IEEE 802 group create their own VSA format. The VSA format defined in [IEEE80211F] is inappropriate for this, since the Type field is only a single octet, allowing for only 255 attributes. It is recommended that IEEE groups read and follow the recommendations in "RADIUS Design Guidelines" [BCP158] and the "Protocol Extensions" ID [RADEXT] when designing and reviewing new extensions and attributes.
[draft-iab-rfc4441rev-04.txt]Appendix A. Current examples of IEEE 802 and IETF
Work Item Collaboration
omniran-13-0032-03-0000
24
CONCLUSIONIEEE 802 Scope of OmniRAN
omniran-13-0032-03-0000
25
Conclusion
• OmniRAN Reference Points can be mapped into the IEEE 802 Reference Model– R1 is completely covered by IEEE 802 specifications– R2 and R3 are related to attributes for control of IEEE 802 functions and the
definition of a DL SAP for the transport of user payload– R4 is not considered by this contribution
• IEEE 802.21 may provide some ideas for its representation in the IEEE 802 views.
– R5 may be completely out of scope of IEEE 802• However attributes of R3 may be copied over to R5
• IP protocols used for OmniRAN are out of scope of IEEE 802• OmniRAN Specification in the scope of IEEE 802 would consist of
– an normative part defining control attributes and a DL SAP for the user payload– an informative part outlining the overall architecture– an informative part proposing the usage of particular IP protocols and the
mapping of the IEEE 802 attributes into the IP protocols.• BTW: The approach seems to be aligned as well with the SDN use
cases.