Information on New IETF Working Groups and Work Areas
fyi. Note mention of 802.17. These five messages were sent out by Matt
Deane, SC6 Secretary.
Jim Carlo(jcarlo@ti.com) Cellular:1-214-693-1776 Voice&Fax:1-214-853-5274
TI Fellow, Networking Standards at Texas Instruments
Vice Chair, IEEE-SA Standards Board
Chair, IEEE802 LAN/MAN Standards Committee
-----Original Message-----
From: Matthew Deane [mailto:mdeane@ANSI.org]
Sent: Tuesday, November 28, 2000 8:28 AM
MESSAGE #1
-----Original Message-----
From: The IESG [SMTP:iesg-secretary@ietf.org]
Sent: Monday, November 20, 2000 4:23 PM
Cc: new-work@ietf.org
Subject: WG Review: IP over Packet Transport Rings (ipoptr)
A new IETF working group has been proposed in the IETF.
The IESG has not made any determination as yet.
The following Description was submitted, and is provided for informational
purposes only:
IP over Packet Transport Rings (ipoptr)
---------------------------------------
Current Status: Proposed Working Group
Mailing Lists:
General Discussion:ptrings@cisco.com
To Subscribe: ptrings-request@cisco.com
In Body: (un)subscribe ptrings
Archive: TBA
Description of Working Group:
Enhancements to traditional bi-directional ring topologies, specifically
those under development within IEEE's 802-RPRSG (Resilient Packet Rings
Study Group), provide substantial benefits in efficiency and flexibility.
Benefits within these MAC layer definitions include spatial re-use as a
result of destination stripping of unicast packets and full utilization of
both counter-rotating rings while still maintaining APS-like protection
switching during fault situations. These Layer 2 MAC definitions are being
developed within the IEEE and will include, among other things, mechanisms
for Topology Discovery, Congestion Control and Protection Switching
Reference IEEE 802-RPRSG at http://www.ieee802.org/rprsg/index.html).
The objective of the IETF's IPoPTR Work Group is to develop a framework and
requirements document that shows how IP can take advantage of features being
developed by the IEEE RPRSG. This work is specifically being done in
parallel with the IEEE effort so that cross fertilization between the IEEE
and IETF groups takes place while the IEEE standard is being developed. In
particular, the framework and requirements document is intended to provide
input to the IEEE RPRSG and to help it formulate its requirements. Specific
areas of interest from the perspective of IP include: interactions between
Layer 2 and Layer 3 functions and features such as alarm notification, fast
restoration, fast convergence, traffic engineering and QoS treatments.
The requirements and framework document will:
* Clearly state requirements for L2-L3 interaction within these rings
* Highlight the motivation and associated benefits
* Define key components, Layer abstractions and partitioning
* Document assumptions, any observations and issues
* Formulate the mechanisms required to accomplish IP-awareness within
these Packet Transport Rings
The WG will not address issues that are clearly within the MAC Layer and
will not develop any protocols at this time. No formal liason with the IEEE
is anticipated. It is expected that individuals will participate directly in
both groups.
MESSAGE #2
From: The IESG [SMTP:iesg-secretary@ietf.org]
Sent: Monday, November 20, 2000 4:32 PM
Cc: new-work@ietf.org <<mailto:new-work@ietf.org>>
Subject: WG Review: Provider Provisioned Virtual Private Networks
(ppvpn)
A new IETF working group has been proposed in the IETF.
The IESG has not made any determination as yet. The following Description
was submitted, and is provided for informational purposes only:
Provider Provisioned Virtual Private Networks (ppvpn)
-----------------------------------------------------
Current Status: Proposed Working Group
Mailing Lists:
General Discussion:nbvpn@bbo.com
To Subscribe: nbvpn-request@bbo.com
<<mailto:nbvpn-request@bbo.com>>
In Body: (un)subscribe
Archive: http://nbvpn.francetelecom.fr
<<http://nbvpn.francetelecom.fr>>
Description of Working Group:
This working group is responsible for defining and specifying a limited
number of sets of mechanisms for supporting provider-provisioned virtual
private networks (PPVPNs). The work effort will include the development of a
framework document, a service requirements document and several individual
protocol profile documents that group a collection of technologies together
to specify a specific type of service offering. The framework will define
the common components and pieces that are needed to build and deploy a
PPVPN.
The service requirement document will detail the requirements individual
PPVPN profiles must satisfy from a Service Provider (SP) perspective.
Particular attention will be placed on SP requirements for scalability and
manageability considering such factors as Service Provider's projections for
number, complexity, and rate of change of customer VPNs over the next
several years. The working group will make specific efforts to solicit this
information from SPs. The service requirements document is not intended to
define the requirements that all profiles must satisfy. Rather, it is
intended to become a "checklist" of requirements, not all of which will
necessarily be required in all deployment scenarios. A goal of the
requirements document is to provide a consistent way to evaluate and
document how well each individual profile satisfies the individual
requirements.
The effort will produce a small number of profiles that are based on
collections of individual technologies that already exist (see below for
specifics). The goal is to foster interoperability among implementations of
a specific profile. Note that it is not a goal of this WG to develop new
protocols or extend existing ones. Rather, the purpose is to document and
identify gaps and shortcomings in individual profiles with regards to the
requirements. In the case that specific work items are identified, such work
will be done in an appropriate WG. Taking on specific protocol work items in
this WG will require rechartering.
The working group is expected to consider (at least) three specific profiles
including BGP-VPNs (RFC 2547), virtual routers and port-based VPNs (i.e.,
where the SP provides a Layer 2 network to the customer such as Frame Relay
circuits). Multiple profiles are being developed as each profile has
particular characteristics and appliciblitly tradeoffs. The working group
will consider inter-AS (SP) VPN interconnects so that VPNs are able to span
multiple ASs (SPs).
Each profile document will include an evaluation of how well it meets the
requirements defined in the requirements document. In addition, profile
documents will address scalability and manageability issues as well as
operational aspects of their approach. Individual profile documents will
also analyze the threat and security aspects of PPVPNs and include
appropriate mandatory-to-implement technologies and management mechanisms to
ensure adequate security and privacy of user data in a VPN environment. An
applicability statement will be developed for each profile that describes
the environments in which the profiles are suitable for deployement.
MESSAGE #3
From: The IESG [SMTP:iesg-secretary@ietf.org]
Sent: Monday, November 20, 2000 3:54 PM
Cc: new-work@ietf.org
Subject: WG Review: Common Control and Measurement Planes (coma)
A new IETF working group has been proposed in the IETF.
The IESG has not made any determination as yet. The following Description
was submitted, and is provided for informational purposes only:
Common Control and Measurement Planes (coma)
--------------------------------------------
Current Status: Proposed Working Group
Organizational Overview
The CoMa working group coordinates the work within the IETF towards defining
a common control plane and a separate common measurement plane for ISP and
SP core tunnel technologies. The purpose of the group, besides specifying
the common control and the common measurement protocols, is to ensure that
inputs and requirements from the MPLS, IPO, PPVPN and TE working groups (and
future ones that may be formed on related topics) are completely taken into
account, and that those working groups (and future related others) produce
results that make best, cleanest use of the commonalities in control and the
commonalities in measurement.
Description of the Working Group:
Over the last few years the need for common control and status protocols for
representing and manipulating layer 1 and 2 resources has become more
urgent. Particularly pressing is the need to accommodate switched optical
networks where the intermediate switches, while controllable via IP-based
protocols, are transparent above the physical layer to the data traffic
flowing through them. From a control perspective, there is the need to
perform such network engineering functions as traffic engineering,
provisioning path protection and restoration, and path preemption in a
common way across both physical and tunneled technologies. Common
measurement is Independent of the actual control regime. It requires the
ability to report on the status and properties of he subcomponent parts of a
network (e.g. lambdas, fibers, PVCs, switch ports, optical cross connects)
to elements such as external servers, the routing plane, or a database, and
to report on the properties and liveness status of paths currently
instantiated.
This working group will tackle the problem of creating both the common
control and common measurement planes for tunnels and phyical paths. It
will deal with the technology-independent control and measurement aspects of
traffic engineering, protection/restoration, and tunnel operation. It will
define protocol support for resource sharing and preemption. It will ensure
that the control and measurement protocols are capable of operation both
within and across administrative boundaries.
Both intra-domain and inter-domain scopes are important, and CoMa will
design with both scopes in mind, however the working group may determine
that intra-domain protocols require faster development than those that cross
administrative boundaries.
Specific tasks for the working group include the following:
* Define a single control protocol and a single measurement protocol
such that they are independent of each other. This allows the measurement
protocol to be used by multiple consumers, including layer 3 routing
protocols, centralized path computation servers, and passive path and
resource monitoring devices, among others. Similarly, it allows the control
protocol to use knowledge obtained by means other than the measurement
protocol. Existing IETF protocols should be used as the basis for both
protocols to every extent possible.
* Define the control protocol and the measurement protocol such that
they support multiple tunnel and physical path technologies (e.g. O-O and
O-E-O optical switches, MPLS, GRE) using input from technology-specific
working groups such as MPLS, IPO, etc.
* Define and incorporate into the control and measurement protocols
those network resource properties that are common across technologies. For
properties which are technology-specific (e.g. wavelength-dependent
dispersion of fiber paths) give guidance to the technology-specific group(s)
for how to incorporate their parameters into the protocols.
* Define how the properties of network resources gathered by the
measurement protocol can be distributed in layer 3 routing protocols, such
as OSPF and ISIS. This includes recommended methods for aggregation and
summarization of data as needed for scalability.
* Define the relationship between layer 3 routing protocols and the
common control protocol for establishing and maintaining paths.
* Using input from the TE working group, ensure that the control and
measurement protocols provide both the information and the control functions
adequate to support the traffic provisioning and engineering operations of
service providers.
* Ensure that multi-layer path protection and restoration functions
are achievable using the defined control and measurement protocols, either
separately or in combination.
* Define protocol support for path measurement and liveness
monitoring, including considerations of what the currency of the measure
data needs to be, how much overhead can be tolerated for such measurement,
and how the measurements impact various control mechanisms (including, but
not limited to the common control protocol).
Working Group Organization
In doing this work, the WG will work closely with the
following
other WGs and constituencies:
* Engage SPs to further refine service requirements from a Service
Provider perspective and to ensure that such a protocol can work reasonably
with existing management and provisioning systems.
* Jointly develop any enhancements or modifications to the traffic
engineering aspects of control plane operation with the TE working group
* Jointly progress any IGP metrics/parameters with the ISIS and
OSPF WGs
* Accommodate technology specific input from the IPO WG, and other
tunnel technologies as needed (e.g. GRE).
In addition, The CoMA WG should ensure good communication with other
standards bodies such as the ITU-T, and interoperability forums such as the
OIF and ODSI engaged in IP/optical control plane work. But as is generally
true with IETF working groups, formal liaison planning will be done by the
IAB, and the communications flow about technical work will be on a technical
and individual contributor basis otherwise.
MESSAGE #4
From: The IESG [SMTP:iesg-secretary@ietf.org]
Sent: Monday, November 20, 2000 4:14 PM
Cc: new-work@ietf.org <<mailto:new-work@ietf.org>>
Subject: WG Review: IP over Optical (ipo)
A new IETF working group has been proposed in the IETF.
The IESG has not made any determination as yet. The following Description
was submitted, and is provided for informational purposes only:
IP over Optical (ipo)
---------------------
Current Status: Proposed Working Group
Mailing Lists:
General Discussion:ip-optical@lists.research.bell-labs.com
To Subscribe:
ip-optical-request@lists.research.bell-labs.com
<<mailto:ip-optical-request@lists.research.bell-labs.com>>
In Body: (un)subscribe
Archive: http://www.bell-labs.com/mailing-lists/ip-optical/
<<http://www.bell-labs.com/mailing-lists/ip-optical/>>
Description of Working Group:
The advent of switched multi-channel (e.g., WDM, DWDM, OTDM) optical
networks using OXCs (Optical Cross-connects) and other optical switching
elements presents many new opportunities for improving the performance of IP
networks and supporting faster and more flexible provisioning of IP
services. However, much needs to be specified before interoperable products
based on these technologies can be deployed in service provider networks.
The work needed in this area includes:
* Document the use of existing framing methods, for IP over optical
channels, and as necessary specify additional framing methods.
* Identify and document the characteristics of the optical transport
network that are important for selecting paths for optical channels,
setting-up optical channels, and and tearing-down optical channels.
* Document the application of the common control and measurement
protocols to the technology-dependent aspects of optical path setup,
teardown, and measurement of optical channels across networks with optical
components.
* Document requirements for control of optical networks by elements
outside the optical network itself.
* Document the use of IP-based protocols for the controlled
dissemination of optical network topology, metric, and constraint
information. Such information can be used for inventory management, path
selection, and other purposes. The information to be exchanged should
accommodate both all optical and optical-electrical-optical switching
technologies.
* If a need is identified to develop new protocols or make
incompatible modifications to existing protocols (e.g., routing and
signaling protocols) to accomplish the above goals, then a recharter must
first be approved before undertaking such work.
The IP over Optical WG will coordinate with relevant working groups within
the IETF to leverage existing work. The WG may also generate requirements
for other IETF WGs as needed.
MESSAGE #5
* To: IETF-Announce: ;
* Subject: A New IETF Work Area
* From: Fred Baker <chair@ietf.org <<mailto:chair@ietf.org>> >
* Date: Mon, 20 Nov 2000 17:14:49 -0500
* Sender: scoya@cnri.reston.va.us <<mailto:scoya@cnri.reston.va.us>>
------------------------------------------------------------------------
Traditionally the IETF has focused its efforts "above the wire and below the
application." Occasionally standards track RFCs have given advice to
application implementors about what application-level commands a user should
be able to execute ( e.g., Requirements for Internet Hosts-Application and
Support - RFC 1123), defined software APIs (e.g., GSSAPI - RFC 2743), and
given advice on the proper use of the features of IETF technology (e.g., Use
of HTTP State Management. - RFC 2964). But mostly we have left the
specifications of applications and how 'wires' such as Ethernet or ATM are
defined and operate to other standards organizations or to the market place.
Over the years the boundary between 'wires' and IP protocols has become
harder to define and the interaction has become more intertwined. For
example, what appear as 'wires' or 'circuits' in a virtual network may in
fact be routed datagrams in an underlying IP network. The topology of
dynamic underlying networks such as ATM and soon switched optical networks
can interact with IP-level traffic engineering and routing. Additionally,
with IETF technologies such as MPLS we are defining a whole new class of
'wires'.
It has become increasingly clear that the IETF needs to develop a systematic
approach to dealing with what we used to describe as "sub-IP" technologies.
This approach should be able to help clarify what specific technologies the
IETF should work on, what technologies we should forward to other
organizations, and what technologies we need to work with other
organizations to develop. In this effort the IETF is not proposing to
develop physical wire technologies such as Ethernet, we are proposing to
figure out common ways to monitor and control such technologies as they
apply to IP networks. The existing and any new IETF sub-IP efforts such as
MPLS should be grouped together under common management. As a first cut at
such a systematic approach the IESG has decided to establish a new sub-IP
pseudo-area. This pseudo-area will be temporarily housed in the General
Area with the IETF Chair acting as Area Director and with the Area Directors
of a number of existing IETF Areas acting as a joint technical and
management team. We do not expect this to be a long term arrangement and
the status of the sub-IP effort will be reviewed during the Spring of 2001.
At that time, the IESG will determine which of the following three options
will be pursued. The IESG could determine that there is a need for a long
term effort in this arena. If that is the case the IESG will establish an
additional IETF Area and ask the nomcom to select one or two Area Directors
to manage it. A second possibility is that the IESG could determine that
there is a need for a short term (one to two year) coordinated effort in
which case the IESG could establish a new temporary area as was done in the
case of IPng and appoint two current Area Directors to manage the effort
co-terminus with their current assignments. The third possibility is that
some of the working groups being moved into the pseudo-area and some of the
new working groups will finish up their work by the fall of 2001 with
insufficient remaining work left over to justify the creation of even a
temporary area. In that case whatever working groups remain would be
dispersed to existing IETF areas. Some existing IETF working groups will be
moved into this pseudo-area and a number of new working groups will be
created. They will be listed under the General Area on the agenda for the
San Diego IETF meeting. There are also some BOFs scheduled to be held in
San Diego that may, if they become working groups, be located in the
pseudo-area. One example is the Circuit over IP BOF (coip).
The existing IETF working groups that will be moved into the pseudo-area are
Multiprotocol Label Switching (mpls) and Internet Traffic Engineering
(tewg).
New and proposed working groups that are being located in this pseudo-area
include: Common Control and Measurement Planes (CoMa), Provider Provisioned
Virtual Private Networks (ppvpn), IP over Packet Transport Rings (ipoptr),
and IP over Optical (ipo). Draft charters for these working groups were
posted earlier today.