Subject: Updated charter

From: Vijay Srinivasan <[email-masked]>
Date: Tue, 28 Mar 2000 00:09:50 -0800

Hi folks,

Here is the updated charter based on comments to the mailing list, as well
as feedback received from attendees at the Adelaide IETF.  We will discuss
this charter at the second MPLS session on Wedneday.

The main changes are to add the following wording to the charter statement:
"The working group will extend the concept of label switching to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas)
and spatial switching (e.g. incoming fiber to outgoing fiber)."

and to remove references to optical crossconnects.

Regarding Loa Andersson's comment:
" 1. The charter says that the WG should co-ordinate the work with other 
   organizations "such as OIF, ITU-T, ANSI, ODSI etc." I've the feeling
   that the list is a bit random. There could be other organizations 
   that should be on that list, what about MSF? This is minor.
   I'm more concerned about the "coordintion/cooperation", what mandated 
   does it vest on who and on behalf of whom? I've a feeling that there 
   might be legal (US legal :-) aspects here."

we would like to reiterate that if a formal liaison 
is required with a particular standards body, the IAB will be contacted 
to set one up.  The above list is by no means intended to be comprehensive.

Regards,
MPLS WG Chairs

-------------------------------------------------
Multiprotocol Label Switching (mpls) Charter

Problem Statement:

Label switching in conjunction with network layer routing has emerged
as an important new technology.  It is actively being applied to
applications such as traffic engineering and virtual private networks.
Among the problems this technology is expected to address are the
following:

1.  Greater flexibility in delivering routing services

Using labels to identify particular traffic which are to receive
special services, e.g. QoS.

Using labels to provide forwarding along an explicit path different
from the one constructed by destination-based forwarding.

2.  Scalability of network layer routing

Using labels as a means to aggregate forwarding information, while
working in the presence of routing hierarchies.

3.  Simplify integration of routers with cell switching based
technologies

a) making cell switches behave as peers to routers (thus reducing
the number of routing peers that a  router has to maintain),

b) by making information about physical topology available to
Network Layer routing procedures, and

c) by employing common addressing, routing, and management
procedures.

4.  Simplify integration of routers with optical cross-connect based
technologies

a) making optical cross connects behave as peers to routers (thus
reducing the number of routing peers that a router has to maintain),

b) by making information about physical topology available to
Network Layer routing procedures, and

c) by employing common addressing, routing, and management
procedures.

High Level Requirements

1.  The solution should be general with respect to data link
technologies. Specific optimizations for particular media will be
considered.

2.  The solution must be compatible with existing internetwork
technologies and routing protocols.

3.  The solution should support a wide range of forwarding
granularities associated with a given label, from a single
application flow to a group of topologically related destinations.

4.  The solution should support operations, administration, and
maintenance facilities at least as extensive as those supported in
IP networks.

5.  The solution should provide stable routing.  The protocols defined
by MPLS must provide protocol mechanism(s) to either prevent the
formation of loops and/or contain the amount of (networking) resources
that could be consumed due to the presence of such loops.

6.  The solution should be very scalable.  Scalability issues will be
considered and analyzed.

Charter Statement:

The working group is responsible for standardizing a base technology
for using label switching in conjunction with network layer routing
and for the implementation of that technology over various link level
technologies, which may include Packet-over-Sonet, Frame Relay, ATM,
Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,...

This includes procedures and protocols for the distribution of labels
between routers, encapsulations, multicast considerations, and the use
of labels to support higher layer resource reservation and QoS
mechanisms.

The working group will extend the concept of label switching to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas)
and spatial switching (e.g. incoming fiber to outgoing fiber).

Objectives:

1.  Specify standard protocol(s) for maintenance and distribution of
label binding information to support unicast destination-based
routing.

2.  Specify standard protocol(s) for maintenance and distribution of
label binding information to support multicast routing.

3.  Specify standard protocol(s) for maintenance and distribution of
label binding information to support hierarchy of routing knowledge
(e.g., complete segregation of intra and inter-domain routing).

4.  Specify standard protocol(s) for maintenance and distribution of
label binding information to support explicit paths in support of
applications such as Traffic Engineering.

5.  Specify standard protocols and procedures to support fast
MPLS-based recovery.

6.  Specify extensions to the protocols and procedures for
signaling and recovery to support time-division, wavelength and
spatial switching. 

7.  Specify standard procedures of carrying label information over
various link level technologies.

8.  Define the support of Differentiated and Integrated Services,
including aggregated QoS, in an MPLS environment.

9.  Specify standard protocols and procedures to support operations,
administration, and maintenance facilities.

10. Specify a link management protocol for link provisioning and
fault isolation, to facilitate LSP recovery.

Coordination:

The working group will coordinate its activities with other working
groups as appropriate.  For specific technologies, the WG will
cooperate with the appropriate standards bodies such as OIF, ITU-T, 
ANSI, ODSI etc. 

Goals and Milestones:

Mar 00 - Produce a document which defines support of Differentiated
         Services (Diff-Serv) over Multi-Protocol Label Switching 
         (MPLS) networks (Standards Track).

Aug 00 - Produce a document which defines operation with "classic" RSVP
         (i.e. non-TE RSVP) for unicast destinations. (Standards Track).

Aug 00 - Produce specifications for protocols and procedures that support
         fault recovery in an MPLS environment.

Dec 00 - Produce specifications for a MPLS control plane for time-division,
         wavelength and spatial switching (Standards Track).

Dec 00 - Produce specifications for a link management protocol for link
         provisioning and fault isolation (Standards Track).

---

From: Eric Gray <[email-masked]>
Date: Tue, 28 Mar 2000 09:52:04 -0800

Vijay,

	Sorry I was unable to attend the meeting.  I have the 
following general observations to make about the updated MPLS
charter.

	There are interesting implications in the new MPLS charter.
The goal of reducing the number of directly connected peers by 
physically co-locating forwarding and routing functionality is made 
simpler by the MPLS technology itself.  At  the same time, reducing 
the number of directly connected peers in any network of a given 
size increases the radius of the network in  terms of the number of 
routers that must be traversed by both routing protocol interactions 
and data being forwarded - thus complicating the process of route 
convergence.  In addition, the goal of being able to peer with devices 
directly connected to each interface may impose requirements for 
additional router protocol support on each and every device.

	I am not saying that this goal is not a good idea, but I think
it is important that people do not get the idea that the goals in the 
updated MPLS charter will result necessarily in cheaper switches or 
more scalable networks unless it is also a goal of the MPLS working 
group to provide routing that is MORE stable than currently existing.  
Which I do not believe is the case, in spite of the ambiguity in bullet 
number 5 under High Level Requirements.

--
Eric Gray