Internet DRAFT - draft-romascanu-opsawg-auto-attach-framework
draft-romascanu-opsawg-auto-attach-framework
Internet Engineering Task Force P. Unbehagen, Ed.
Internet Draft D. Romascanu
Intended status: Informational J. Seligson
Expires: February 2017 C. Keene
Avaya
August 2016
A Framework for Automatic Attachment of Network Objects to Core
Networks
draft-romascanu-opsawg-auto-attach-framework-01.txt
Abstract
This informational document describes a method that allows for the
automatic attachment of network objects (e.g. end stations, network
devices, sensors, automation elements) to a core network based on
the individual services that are run or configured on the objects,
and the mapping of the services to the managed paths in the network.
The framework proposed by this document describes the operations
that need to happen in order to have the network objects connected
to the network ('attached') in an automatic manner and start
providing their functionality and services without any requirement
or dependency between the protocol stack on the network objects and
the method used to build the bridging or routing paths in the
network core.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 are draft documents 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
Unbehagen, Romascanu Expires February 18, 2017 [Page 1]
Internet-Draft Auto-attach Framework August2016
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 18, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction .............................................. 3
2. Terminology and Abbreviations.............................. 3
3. Requirements Language...................................... 4
4. Auto Attachment Framework, Model and Components............ 4
4.1. Discussion ............................................. 6
5. Auto Attachment Process.................................... 6
5.1. Element Discovery....................................... 6
5.2. Services Configuration.................................. 7
6. Security Considerations.................................... 8
7. IANA Considerations........................................ 9
8. Further and Related Work................................... 9
9. Acknowledgments ........................................... 9
10. References .............................................. 10
10.1. Normative References.................................. 10
10.2. Informative References................................ 10
Unbehagen, Romascanu Expires February 18, 2017 [Page 2]
Internet-Draft Auto-attach Framework August2016
1. Introduction
Large networking deployments are often faced with the problem of
connecting 'legacy' end stations to an upgraded network
infrastructure, or with the demand to interconnect large numbers of
network objects that perform different tasks, transmit information,
or and controlled remotely across this network infrastructure. This
informational document describes a method that allows for the
automatic attachment of network objects (e.g. end stations, network
devices, sensors, automation elements) to a core network based on
the individual services that are run or configured on the objects,
and the mapping of the services to the managed paths in the network.
The framework proposed by this document describes the operations
that need to happen in order to have the network objects connected
to the network ('attached') in an automatic manner and start
providing their functionality and services without any requirement
or dependency between the protocol stack on the network objects and
the method used to build the bridging or routing paths in the
network core.
2. Terminology and Abbreviations
AAC - Auto Attach Client agent that resides on a non-SPB/PBB
capable element that uses LLDPDUs to request I-SID assignment for
the VLANs which have been configured on its network port.
AAS - Auto Attach Server agent that processes VLAN to I-SID requests
from AAC elements that are connected to a SPB BEB
Element - Any end device or network node that may implement the auto
attach functionality
LAN - Local Area Network
LLDP - Link Layer Discovery Protocol
MUD - Manufacturer User Description
VLAN - Virtual Local Area Network
Unbehagen, Romascanu Expires February 18, 2017 [Page 3]
Internet-Draft Auto-attach Framework August2016
3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
4. Auto Attachment Framework, Model and Components
This section provides an overview of the behavior of auto attachment
functionality. The scheme proposed in this document is applicable at
the link layer or at the network layer. Is the currently subject of
proposed standardization work in the IEEE 802.1 Working Group [AA],
and it is consistent with work proposed in the IETF in the Network
Virtualization Overlays (nvo3) and Interface to the Routing System
(i2rs) Working Groups.
The purpose of Auto Attach is to allow an end-device to connect to a
networking device at the edge of a bridged or routed network in the
core without any further knowledge or assumption of the protocol(s)
being run in the core. The end-device is called an AA client (AAC)
and the networking device at the edge of the core network is called
the AA server (AAS). An AA Client is a device that does not support
the bridging or routing protocol in the core but supports some form
of binding definition between the applications or services that it
is running and the format of the data packets that it sends to the
network (for example VLAN tags, or tunnel identifiers), if
connectivity permits, has the ability to advertise this data to a
directly connected AA Server. An AA Server is network device that
potentially accepts externally generated service to tags or tunnels
assignments that can be used for automated configuration purposes.
The client identifies itself to the server and then requests service
to tags binding(s). The server will either accept or reject each
binding request. If accepted, any traffic on the (locally
significant) VLAN or tunnel is forwarded through the routed network
at the parameters required by the service.
The simplification brought by the auto-attachment scheme consists of
the use of widely deployed protocols on the first hop connection
between the AAC and the AAS which allow for the interaction between
the two entities to happen in an automatic manner, without requiring
manual configuration of attachment information at multiple
locations. AACs that utilize this automated method for service
assignment pass the assignment information to the AASs where the
mappings are processed and approved or rejected. Specific actions
are taken on both entities based on the outcome of the mapping
request.
Unbehagen, Romascanu Expires February 18, 2017 [Page 4]
Internet-Draft Auto-attach Framework August2016
Auto Attachment Controller
(SDN/Policy Server)
| |
(6) | (6) |
V V
+--------+ +--------+ +---------+
|estation| | | | |
| AAC |---------| AAS |---------| core |
| (3) | | (3) | | Network |
+--------+ +--------+ +---------+
<----------(1)--------> <-------(2)------>
<----------(4)--------> <-------(5)------>
Figure 1: Conceptual Auto Attach Model
(1) Auto-Attachment Primitives
(2) Routing Control Plane
(3) 'horizontal' data model
(4) Service Tag
(5) Service Route/Tunnel ID
(6) 'vertical' data model
Figure 1 depicts a conceptual example of the process where an AAC
can use a one-hop protocol (1) e.g. LLDP that includes the Auto-
Attachment Primitives to communicate the need to connect a service
to the appropriate route or tunnel in the bridged or routed network
which runs the core bridging or routing protocol (2). A 'horizontal'
data model (3) is shared by the AAC and AAS and synchronized after
the initial exchange of information. If the binding requests are
being accepted, the AAC will start sending traffic using the service
tag (4), traffic which will be routed or tunneled appropriately in
the bridged or routed paths (5). The policy data model (6) allows
for the interaction between the network devices and the end-stations
to a policy server, allowing for the integration of AA scheme in a
policy-based service management environment.
An Auto Attach Client (AAC) can run in any device (end station,
estation) that connects to a core network. One field of applications
can be for example Internet of Things (IoT) devices that connect to
Unbehagen, Romascanu Expires February 18, 2017 [Page 5]
Internet-Draft Auto-attach Framework August2016
a network. The service association is automated with relative low
resources, allowing connection of the devices to the appropriate
network services and applications.
The different classes of devices that run AACs may be configured by
means that are specific for the respective classes of applications
or services. A YANG module may instantiate the 'vertical' data model
(6) of the Auto Attachment framework allowing for standard-based
interaction with the Auto Attachment Controllers, which are
instantiated as policy or Software Define Networks (SDN) servers.
4.1. Discussion
At least one proprietary implementation introduces the concept of an
Auto Attach Proxy. Such an optional block placed between an AAC and
AAS would allow for multiplexing and/or virtualizing the access to
servers. At this phase we decided to leave this optional block for
further study.
5. Auto Attachment Process
The auto-attachment process is composed of a one-hop two steps
protocol that performs the following functions:
- Element Discovery
- Services Configuration
5.1. Element Discovery
The first stage of establishing AA connectivity involves element
discovery. An Auto Attach agent resides on all capable elements.
Server agents control the Auto Attach (AA) of service tags to routes
or tunnels when enabled to accept and process such requests from AAC
elements. Typically this is done through a global service setting
and through per-port settings that control the transmission of
information in the one-hop protocol (1) on the appropriate links
that interface AAC's and AAS's.
Once the required AA settings are enabled on the elements (e.g., the
AA service and the per-port AA settings) the AA agent on each
element type, both AAC and AAS, advertises its capabilities (i.e.,
server/client) through protocol (1) primitives to each other.
Following discovery of AA capabilities by both the AAC and the AAS,
the AA agent on each element is aware of all AA services currently
provided by the network elements to which it is directly connected.
Based on this information, an AAC agent can determine whether Auto
Unbehagen, Romascanu Expires February 18, 2017 [Page 6
Internet-Draft Auto-attach Framework August2016
Attach data, namely locally administered assignments, should be
exported to the AAS that is associated with an edge networking
device to which it is attached to on its network uplink ports.
5.2. Services Configuration
Service mappings can be established when these two criteria are met:
1. AA Server found during discovery
AAC - - AAS peering was established during the discovery
process
2. Service Tags / Routes mapping are defined locally
Assuming that an administrator has defined one or more tags /
routes mappings, or AAC bindings have been received for
processing
Each mapping assignment in an AA request received by the AAS is
processed individually and can be accepted or rejected. An
assignment may be rejected for a number of reasons, such as server
resource limitations or, for example, restrictions related only to
the source AAC. Rejected assignments are passed back to the
originating AAC with a rejected state and, if appropriate, an
indication as to why the rejection occurred. Limited state
information may be maintained on the server related to rejected
assignments.
Each route (or tunnel, or VLAN) that is associated with an accepted
assignment is instantiated on the AAS bridge if it does not already
exist.
The AAS agent is responsible for tracking which, if any, of these
actions are performed so that settings can be cleared when they are
no longer needed. This can occur, for example, when configuration
changes on an AAC updates the received assignment list when an AAC
associated with a downlink port changes or an AAC connection
disappears entirely.
Each station tag (e.g. VLAN, subnet) that is associated with a
service assignment must be defined on the client's device. The port
associated with the uplink connecting the AAC to the AAS must be a
member of the VLAN or Subnet assignment lists that are sent to and
accepted by the AAS. This allows tagged traffic on to pass through
the edge networking device into the core routed network when
required. To ensure that markings are maintained between devices,
Unbehagen, Romascanu Expires February 18, 2017 [Page 7]
Internet-Draft Auto-attach Framework August2016
traffic on the uplink port MUST be tagged. If a tag has not been
created before the assignment itself, it is automatically created by
the AAC agent when a proposed assignment is accepted. Port tagging
and the port VLAN or subnet membership update are also performed by
the AAC automatically based on assignment acceptance. To ensure
consistency, tags SHOULD NOT be deleted as long as they are
referenced in any I-SID/VLAN assignments on the device.
An AAC must handle primary AAS loss and this requires maintenance
of a server's inactivity timer. In order to make this possible a
time-alive mechanism needs to be implemented between any AAC and its
primary AAS. If an interruption of communication is detected, the
service is considered interrupted, the service tags / routes
assignments accepted by the server are considered rejected.
Assignment data is then defaulted (reverts to the 'pending' state)
and the AA agent, which resides on the AAC, removes related
settings. If a back-up mechanism (alternate routes to the primary
AAS, secondary AAS) exists it will be activated.
A "last updated" timestamp is associated with all active assignments
on the AAS. When this value is not updated for a pre-determined
amount of time, the service tags / routes assignment is considered
obsolete. Obsolete assignment data and related settings are removed
by the AAS.
The current routes / tags assignment list is advertised by an AAC at
regular intervals. During processing of this data, an AAS must
handle list updates and delete assignments from previous
advertisements that are no longer present. Though these entries
would be processed appropriately when they timeout, the AAS attempts
to update the data in real-time and SHOULD initiate deletion
immediately upon detection of this condition.
6. Security Considerations
It is important to provide an option to ensure that the
aforementioned Auto Attach communication is secure in terms of data
integrity (i.e., the data has not been altered in transit) and
authenticity (i.e., the data source is valid).
There are several ways this can be ensured:
- Assume that the one-hop link between the end device and the
network device makes use of certificate based authentication like
IEEE 802.1AR [AR] certificates
- Check data integrity and perform source validation by using an
optional keyed-hash message authentication code (HMAC) to protect
Unbehagen, Romascanu Expires February 18, 2017 [Page
Internet-Draft Auto-attach Framework August2016
the Discovery and Configuration message exchanges. This type of
message authentication allows communicating parties to verify that
the contents of the message have not been altered and that the
source is authentic. Use of this mechanism is optional and is
controlled through a user-configurable attribute.
7. IANA Considerations
This memo includes no request to IANA.
Note: the section will be removed during conversion into an RFC by
the RFC Editor.
8. Further and Related Work
- Standard extensions to the IEEE 802.1AB (LLDP) [LLDP] protocol are
developed by the IEEE 802.1 Working Group. The relevant project is
IEEE 802.1Qcj [AA] for 'Automatic Attachment to Provider Backbone
Bridges (PBB) services'.
- Element Discovery could be implemented by using one of the
protocols that implement the Manufacturer User Description
Specification [MUD-SPEC]. The MUD LLDP Extension, the MUD URL DHCP
Option and the MUD URC X.509 Extension defined in [MUD-SPEC] can
be used for the purpose of instantiating the Discovery process.
9. Acknowledgments
The first version of this document that introduced the auto attach
concept was co-authored by Nigel Bragg and Ludovic Beliveau.
We would like to thank the following people (in no particular order)
for their contributions:
Zenon Kuc
Cristian Mema
Roger Lapuh
Craig Griffin
Chris Buerger
Keith Krajewski
Eliot Lear
Unbehagen, Romascanu Expires February 18, 2017 [Page 9]
Internet-Draft Auto-attach Framework August2016
This document was prepared using 2-Word-v2.0.template.dot.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LLDP] IEEE STD 802.1AB, "IEEE Standard for Local and
Metropolitan Area Networks-- Station and Media Access
Control Connectivity Discovery", 2005.
[AR] IEEE STD 802.1AR, "IEEE Standard for Local and metropolitan
area networks - Secure Device Identity", 2009.
10.2. Informative References
[AA] IEEE 802.1Qcj, "Standard for Local and Metropolitan Area
Networks-Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks Amendment: Automatic
Attachment to Provider Backbone Bridging (PBB) services"
[MUD-SPEC] Lear E. and R. Droms, "Manufacturer Usage Description
Specification",draft-lear-ietf-netmod-mud-04 (work in
progress), August 2016.
Authors' Addresses
Paul Unbehagen Jr., editor
Avaya
1300 W. 120th Avenue
Westminster, CO 80234
US
Email: unbehagen@avava.com
Dan Romascanu,
Avaya
Azrieli Center Holon
26, HaRokhmim Str., Bldg. D
Holon, 5885849
Unbehagen, Romascanu Expires February 18, 2017 [Page 10]
Internet-Draft Auto-attach Framework August2016
Israel
Phone: +972-3-645-8414
Email: dromasca@avaya.com
John Seligson
Avaya
4655 Great America Parkway
Santa Clara, CA 95054
US
Email: jseligso@avaya.com
Carl Keene
Avaya
600 Technology Park Dr
Boston, MA 01821
US
Email: ckeene@avava.com
Unbehagen, Romascanu Expires February 18, 2017 [Page 11]
