Draft PAR Title, Scope, Purpose, WhyNeeded, and 5 Criteria for
Management of data driven and data dependent connectivity faults (DDCFM) - revision 0.1

As discussed at the 802.1 Beijing interim meeting in May 2006, I am circulating a preliminary draft for a DDCFM PAR, for discussion at the July 2006 Plenary in San Diego.

 Background information can be found in:

.../docs2006/new-seaman-ddcfm-note-0306-01.pdf

and

.../docs2006/new-seaman-ddcfm-0306-02.pdf

 Broadly speaking this proposed work meets the expressed need for an OAM capability corresponding to the “payload loopback” available in other types of networks in a way that does not itself interfere with the operation of bridges and bridged networks, and that can provide improved fault isolation. The work is intended to comprise very modest additions to the CFM capabilities that P802.1ag will add to 802.1Q, but standardization is needed as the effectiveness of the solution depends on consistent multi-vendor handling of two assigned CFM code points.

 The intention at the July meeting is to improve this first draft PAR and to seek an 802.1 resolution for further editing and subsequent pre-circulation of a preliminary PAR to the 802 Exec in advance of the November 802 plenary, with final 802.1 editing of the PAR and submission to the Exec for forwarding to Nescom in November. In terms of overall project planning it is the definite intent to ensure that this work does not interfere with timely progression of P802.1ag to sponsor ballot, nor to begin significant work until P802.1ag has progressed at least that far. The only coupling effect should be an examination of the structure of P802.1ag to ensure ourselves that it is in a reasonable shape to accommodate amendments (in general) that will extend its ‘first release’ functionality. The point of getting the project planning for DDCFM underway now is to avoid an unnecessary gap in CFM related developments, and to reduce any desire to hold up .1ag just to add this ‘one little thing’.

 In the interest of making the best use of our time during the July meeting it is not my intent to repeat the presentation of the background information (above), but to focus on project related questions and draft PAR editing. It would help if those who did not see the prior presentations could look at them before the meeting so we could focus on questions arising rather than repetition.

Title:

Standard for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks – Amendment 10?: Management of data driven and data dependent connectivity faults

Scope:

This standard specifies  connectivity fault management protocols, procedures, and managed objects that provide confirmation of successful transmission of frames conveying specified data. This capability supports diagnosis of faults sensitive to, or caused by, particular data patterns, and their isolation to part of the transmission path. Connectivity verification can be carried out from any single point with bridged connectivity to maintenance points on the path, can isolate failures to communicate in a specific direction, and can be carried out while service is being provided to other users of the data path.

Purpose:

While bridged networks are notionally transparent to the users’ data, they are often deployed as part of a service offering that selectively filters data frames (e.g. firewall functionality), automatically configures some aspect of service in response to data frames (e.g. IGMP snooping), or is supported by transmission in a data sensitive way (e.g. IEEE Std 802.3ad Link Aggregation). This standard will define the protocols (including CFM OpCodes) and managed objects required for data sensitive connectivity verification that is multi-vendor and uses  the framework provided by IEEE P802.1ag Connectivity Fault Management.

WhyNeeded:

 There is considerable demand, from the service providers that currently use or plan to use IEEE 802.1 bridging standards, for diagnostic functionality that is at least equivalent to that provided by loopback for other network technologies, and operates in a broadly similar way. A straight forward application of loopback to IEEE 802.1Q networks is known to cause problems that can be hard to diagnose while not addressing complex fault scenarios, but is likely to be widely implemented in the absence of a better standard solution. The proposed amendment offers that solution.

5 Criteria

 1. Broad Market Potential

A standards project authorized by IEEE 802 shall have a broad market potential.  Specifically, it shall have the potential for:

a) Broad sets of applicability.

 IEEE 802.1 bridging standards have been widely adopted by the service provider community. The proposed standard will address their need to use operate their new IEEE 802.1/IEEE 802.3 networks while retaining familiar procedures derived from past experience. The connectivity fault management capability provided by the proposed standard can be used with the minimum of management access to the equipment supporting user services, consistent with the approach developed in P802.1ag with joint membership collaboration with the ITU. As with P802.1ag as a whole, improvements in connectivity fault management and the ability to diagnose connectivity failures with no or little management access to network equipment is expected to be of utility to the broad community of IEEE Std 802.1Q users.

 b) Multiple vendors and numerous users.

 There is broad interest from numerous vendors in IEEE 802.1 in meeting the need expressed by multiple service provider customers needs for a CFM capability equivalent to ‘payload loopback’.

 c) Balanced costs.

This capability is not expected to materially increase the cost of individual VLAN bridges that are suitable for service provider applications, and in part standardization is required so that two specific CFM OpCodes can be defined as being ignored by bridges that simply have to forward diagnostic traffic.

2. Compatibility

IEEE 802 defines a family of standards.  All standards shall be in conformance with the IEEE 802.1 Architecture, Management and Internetworking documents as follows: 802. Overview and Architecture, 802.1D, 802.1Q and parts of 802.1f.  If any variances in conformance emerge, they shall be thoroughly disclosed and reviewed with 802.

Each standard in the IEEE 802 family of standards shall include a definition of managed objects which are compatible with systems management standards.

 This amendment will not change the conformance of IEEE Std 802.1Q to Std 802. Overview and Architecture, or its relationship to that specification.

 Equipment conforming to the proposed amendment to IEEE Std 802.1Q will be compatible and interoperable with bridge implementations that conform to IEEE Std 802.1D and prior revisions of IEEE Std 802.1Q, and support of existing network configurations will be retained in parallel with use of the additional capabilities provided by this amendment. No change to end stations will be required to take advantage of these capabilities.

 This amendment will include extensions to MIBs, existing or under development as part of other 802.1 projects, to allow management of DDCFM as a natural extension of existing capabilities.

 3. Distinct Identity

Each IEEE 802 standard shall have a distinct identity.  To achieve this, each authorized project shall be:

a) Substantially different from other IEEE 802 standards

 IEEE Std 802.1Q is the sole and authoritative specification for VLANs and VLAN-aware Bridges, and for Connectivity Fault Management of networks constructed using that technology.

 b) One unique solution per problem (not two solutions to a problem).

 The proposed amendment will extend existing VLAN technology and has not been anticipated by any other specification, in IEEE 802 or elsewhere.

 c) Easy for the document reader to select the relevant specification.

 IEEE Std 802.1Q is the natural reference for VLAN bridging technology, which will make the capabilities added by this amendment easy to locate.

 4. Technical Feasibility

 For a project to be authorized, it shall be able to show its technical feasibility.  At a minimum, the proposed project shall show:

 a) Demonstrated system feasibility.

 The proposed amendment is based on known 802.1Q VLAN technology.

 b) Proven technology, reasonable testing.

 The proposed amendment is based on known 802.1Q VLAN technology.

 c) Confidence in reliability.

 The reliability of this solution is anticipated to be the same as that of others based on existing 802.1Q VLAN technology.

 d) Coexistence of 802 wireless standards specifying devices for unlicensed operation.

 Not applicable.

 5. Economic Feasibility

 For a project to be authorized, it shall be able to show economic feasibility (so far as can reasonably be estimated), for its intended applications.  At a minimum, the proposed project shall show:

 a) Known cost factors, reliable data.

 The proposed technology is no expected to materially alter individual VLAN Bridge equipment costs, while addressing an operational need in service provider networks that use that equipment. Relative to fostering the development of proprietary solutions with differing approaches and concepts the proposed standard will help to contain operational costs.

 b) Reasonable cost for performance.

 The operational practice that requires the development of the proposed standard has a long history, perceived utility, and considerable cost experience by the users’ of 802.1 standards that want it supported by IEEE 802.1 conformant equipment.

 c) Consideration of installation costs.

 Installation costs of VLAN Bridges are not expected to be affected in  any way.