/
IEEE 802.1ABrev Extension for Auto Attach IEEE 802.1ABrev Extension for Auto Attach

IEEE 802.1ABrev Extension for Auto Attach - PowerPoint Presentation

liane-varnes
liane-varnes . @liane-varnes
Follow
369 views
Uploaded On 2015-10-22

IEEE 802.1ABrev Extension for Auto Attach - PPT Presentation

Nigel Bragg Dan Romascanu Paul Unbehagen Scope Define a method of using IEEE 8021AB Link Layer Discovery Protocol LLDP with IEEE 8021aq Shortest Path Bridging SPB network to automatically attach network devices not supporting IEEE 8021ah to individual services in a SPB network ID: 168450

ieee 802 proposed standard 802 ieee standard proposed project 1ab octets lldp bits costs requirements feasibility spb 1aq lmsc

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "IEEE 802.1ABrev Extension for Auto Attac..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

IEEE 802.1ABrev Extension for Auto Attach

Nigel

Bragg

Dan

Romascanu

Paul

UnbehagenSlide2

Scope

Define a method

of using IEEE 802.1AB Link Layer Discovery Protocol (LLDP) with IEEE 802.1aq Shortest Path Bridging (SPB) network to automatically attach network devices not supporting IEEE 802.1ah to individual services in a SPB network

.

These network devices typically do not support SPBM, MAC- in-MAC (802.1ah), nor I-SID usage and therefore cannot easily take advantage of the SPB infrastructure without manual configuration of attachment of VLANs to I-SIDs in multiple

locations

Develop the extra MIB objects to the LLDP MIB as needed Slide3

Conceptual SPB Auto Attach Model

SPB Network

BEB Server

Client

SPBM

VLAN

ISID

LLDPSlide4

LLDP Extensions

Type: 127 (7 bits)

Length: 16 octets (9 bits)

OUI: 3 octets

Subtype: 8 (1 octet)

Element Type: 4 bits

Mgmt VLAN: 12 bits

System ID: 10 octets

Type: 127 (7 bits)

Length:

41-506 octets

OUI: 3 octets

Subtype:

9

(1 octet)

HMAC-SHA256 Digest: 32 octets

VLAN: 12 bits

I-SID: 3 octets

AA Element TLV

Service Assignment TLV

Assignment Status: 4 bitsSlide5

Applications

Uses for Auto Attach (AA) have been identified for numerous cases where end devices need to signal the need to associate itself with specific virtual networks identified by an ISID

A prototype functional model was created using Open

vSwitch

(OVS

)

Using a Standard 1U switch, OVS with LLDP TLV extensions, and a state machine to manage the communication of tlv’s.Creation and movement of VM’s triggered the creation of AA LLDP TLV’s to the

ToR’s from one server to another.Slide6

Options

Do nothing in IEEE 802.1

may follow

draft-

unbehagen

-lldp-spb

as Informational RFCAs part of IEEE 802.1AB-REVNew (small) project to amend IEEE 802.1AB… in which case the coming slides applySlide7

Project process requirements

Coexistence

A WG proposing a wireless project shall demonstrate coexistence through the preparation of a Coexistence Assurance (CA) document unless it is not applicable.

Will the WG create a CA document as part of the WG balloting process as described in Clause 13? (yes/no)

If not, explain why the CA document is not applicable.

Not applicable – this is not a wireless project.Slide8

5C requirements

Broad market potential

Each proposed IEEE 802 LMSC standard shall have broad market potential. At a minimum, address the following areas:

Broad sets of applicability.

Multiple vendors and numerous users.

The proposed revision would apply to all 802 networks that implement IEEE 802.1AB and IEEE 802.1aq

Some vendors and users have expressed their support for this extensions and there are a number of implementations successfully deployed in the field.Slide9

5C requirements

Compatibility

Each proposed IEEE 802 LMSC standard should be in conformance with IEEE Std 802, IEEE 802.1AC, and IEEE 802.1Q. If any variances in conformance emerge, they shall be thoroughly disclosed and reviewed with IEEE 802.1 WG prior to submitting a PAR to the Sponsor.

Will the proposed standard comply with IEEE Std 802, IEEE Std 802.1AC and IEEE Std 802.1Q?

If the answer to a) is no, supply the response from the IEEE 802.1 WG.

The review and response is not required if the proposed standard is an amendment or revision to an existing standard for which it has been previously determined that compliance with the above IEEE 802 standards is not possible. In this case, the CSD statement shall state that this is the case.

Yes.Slide10

5C requirements

Distinct Identity

Each proposed IEEE 802 LMSC standard shall provide evidence of a distinct identity. Identify standards and standards projects with similar scopes and for each one describe why the proposed project is substantially different.

There is no other 802 standard or approved project that provides the same functionality for bridges or end stations.Slide11

5C requirements

Technical Feasibility

Each proposed IEEE 802 LMSC standard shall provide evidence that the project is technically feasible within the time frame of the project. At a minimum, address the following items to demonstrate technical feasibility:

Demonstrated system feasibility.

Proven similar technology via testing,

modeling

, simulation, etc.

There are numerous implementations of the

IEEE 802.1AB and IEEE 802.1aq standards. This proposal represents an extension of the first

The technology has been proven in the field and in compatibility testing carried out in testing labs.Slide12

5C requirements

Economic Feasibility

Each proposed IEEE 802 LMSC standard shall provide evidence of economic feasibility. Demonstrate, as far as can reasonably be estimated, the economic feasibility of the proposed project for its intended applications. Among the areas that may be addressed in the cost for performance analysis are the following:

Balanced costs (infrastructure versus attached stations).

Known cost factors.

Consideration of installation costs.

Consideration of operational costs (e.g., energy consumption).

Other areas, as appropriate.

The functionality needed to provide the features specified in this standard is essentially the same in bridges and end stations. The cost of providing these features in each type of device will not be significant, given the expected large volumes.

The cost factors are well known from implementations of IEEE 802.1AB. We are basically talking about a software upgrade

There are no incremental installation costs relative to the existing costs associated with

IEEE 802.1AB and IEEE 802.1aqThere are no incremental operational costs relative to the existing costs associated with

IEEE 802.1AB and IEEE 802.1aqNo other areas have been

identified.