Subject: Alternative MPLS Label Stack Encoding

From: Michael Stefan Cox <[email-masked]>
Date: Fri, 24 Sep 1999 16:59:04 +1000

All,
	I have some concerns with the current label stack encoding that I believe
are very significant. Although the modifications proposed within this email
are relatively minor with respect to HW/SW implementations they potentially
represent a structural change to the bit ordering. I believe these
modifications are necessary to facilitate several advanced services and
capabilities that are primarily market oriented and are not easily
implemented using any other mechanism. MPLS is becoming a vital strategic
technology in the general marketplace and as such it would be devastating to
the industry to define a label encoding that falls short of its unique
potential.

---------------------------------------------------------------------------

Background:
	MPLS represents one of the most significant technologies currently being
developed within the IETF. It is shaping up to be a vital technology for
enabling a number of critical new services for IP within the marketplace.
Each of these services potentially offers new revenue sources to increase
profitability and capabilities to increase the performance and reliability
of IP networks globally. The work so far completed in standardising MPLS
represents a significant undertaking by the MPLS WG, but the full potential
of this technology is yet to be determined.

This email proposes a definition of the 3 "Experimental" (EXP) bits
currently reserved within the MPLS label stack encoding to provide a
powerful set of service and feature enablers in an elegant and flexible
manner. This proposed definition does not in any way detract from MPLSs
ability to be implemented efficiently in both hardware and software, rather
it simply expands MPLS's capabilities in a manner consistent with its design
[draft-ietf-mpls-arch-06.txt]. In the process this definition will
ultimately lead to a desire to rearrange the bit fields within the header to
improve the readability and presentation of the label encoding. Although the
location of the bit fields is inconsequential to <most/all> HW and SW
implementations and as such can be left as currently defined, it will become
apparent that this would be sub-optimal from a solution point of view.

---------------------------------------------------------------------------

Requirement:
	Most vendors and service providers are currently planning to deploy MPLS as
a transport mechanism in one of two fundamentally different ways. The first
is based on the current definition of MPLS in terms of IP Forwarding
Equivalence Classes (IP-FECs). The second is based on the many proposals to
use MPLS as an Explicit Route Traffic Engineering (ER-TE) mechanism. In
addition to these primary transport uses, many others have proposed further
uses for MPLSs unique label stacking mechanism. These include the ability to
scale central office (CO) based virtual private routed network (VPRNs)
implementations by stacking an egress selector or network identifier as the
first label and a transport label (as defined above) as the second label. As
well as the ability to improve network scalability by performing label
aggregation, via a push operation, to transit a core domain and then
continue forwarding on egress from the core with no loss in path
granularity, via a pop operation.

In the IP-FEC mode each MPLS switch is implicitly also an IP router and as
such is typically termed a Label Switch(ing) Router (LSR). In this model the
label mappings are determined by the IP routing protocols and thus tend to
be very much "topology" driven. When topology changes occur due to failure
or overload, the routing protocols converge on the new topology and assign
new label mappings as appropriate. In this environment, as in the native IP
routing environments, loops can occur (albeit momentarily) and thus it is
vital that some other form of loop effect minimisation is employed such as
implementing time to live (TTL) counters. Functionality such as DiffServ
PHBs and IP ICMP signalling can be implemented by delving into the label
stack to the embedded IP payload and retrieving values from there.

In the ER-TE mode an MPLS switch need not have IP routing capabilities (i.e.
it can be just a high performance Label Switch (LS) as in MPLS over ATM) and
the Label Switched Paths (LSPs) are typically not topology driven by the IP
routing protocols. In this environment forwarding loops are explicitly
prevented through the use of either global topology knowledge (centralised
offline system), explicit loop prevention via route recording (RSVP) or
other loop-free signalling/provisioning systems. A current debate regarding
ER-LSPs is whether or not the Class of Service (CoS) should be implied from
the label mapping (ie a label per CoS) or whether DiffServ codepoint type
mechanisms (multiple CoS per label) should be supported. The proposal of
this email addresses elegantly both requirements as the author foresees a
need for both depending on the underlying technologies used and the higher
protocols to be supported. For instance a distributed, automated traffic
engineering system would be most scalable if multiple CoSs per LSP were
supported, likewise for reverse Label-Merged source rooted multicast trees.
In these environments it is critical that we decouple the concept of
Forwarding based on the label (for Traffic Engineering purposes) and
Queueing based on the DS-Codepoint (for providing the Differentiated CoS).

The possibilities however do not end here. MPLS uniquely provides us with a
standard mechanism that allows us to arbitrarily extend the Layer-3 protocol
headers as necessary or desired on a per peer, vendor, AS or global scale.
Compare this with the inflexibility of ATMs basic two level approach (VP,
VC). This capability allows vendors and service providers to support complex
functions such as categorising payloads for edge-to-edge differentiation (as
opposed to hob-by-hop differentiation [DiffServ RFC 2474, 2475]), providing
payload colouring on the basis of source/type/flowspec/etc whilst
maintaining a state-free core transit domain, supporting stateless
distributed payload identification without the need for centralised
correlation, supporting true multi-protocol encapsulation and finally
providing direct support for Differentiated Services per hop behaviours
(DS-PHBs) in the outer-most label for QoS. With an appropriately flexible
definition of the label encoding the possibilities are boundless. The
extensions proposed below provide such a flexible definition to the current
label stack encoding.

---------------------------------------------------------------------------

Drivers:
	The following definitions for the EXP field of the MPLS label stack
encoding, and their implications on the other bits in the header, have
designed with the following goals in mind:
- Provide simple, elegant and flexible support for both transport paradigms
(IP-FEC and ER-TE).
- Permit easy interchange (mode swapping) from IP-FEC to ER-TE and
vice-versa.
- Allow for a Virtual Private Network identifier (Layer-3 address extender)
and maximise its size (for scalability).
- Allow for arbitrary (AS or vendor specific) marking of payloads for
Edge-to-edge differentiation.
- Allow for future extensibility without loss of generality.
- Allow for IP header field extension to support unforeseen future
requirements via the label stacking mechanism.
- Maintain full compatibility with the existing proposal if preferred.

---------------------------------------------------------------------------

Current Label Stack Encoding (draft-07):
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
  |                Label                  | Exp |S|       TTL     | Stack
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                       Label:  Label Value, 20 bits
                       Exp:    Experimental Use, 3 bits
                       S:      Bottom of Stack, 1 bit
                       TTL:    Time to Live, 8 bits

---------------------------------------------------------------------------

First Proposal:
	The proposal is to define a number of Label types which are distinguished
by the coding of the EXP field. The proposed encodings are:
		EXP = xx0, Label Type 1 : VPN Identifier.
		EXP = 001, Label Type 2 : IP-FEC Label.
		EXP = 011, Label Type 3 : ER-TE Label.
		EXP = 101, Label Type 4 : AS specific.
		EXP = 111, Label Type 5 : Reserved.
These are defined in more detail immediately below.

Type 1 = VPN identifier:
	When the least significant bit of the EXP field is a 0 then the label
encodes a Virtual Private Network Identifier (VPN_id). The most significant
22 bits (VPNid_high) and the least significant 8 bits (VPNid_low) are
encoded separately to define a 30 bit total VPN_id when concatenated
together.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
  |                 VPNid_high                |0|S|   VPNid_low   | Stack
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

Type 2 = IP-FEC label (original):
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
  |                Label                  |0 0 1|S|       TTL     | Stack
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

Type 3 = ER-TE label (diffserv):
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
  |                Label                  |0 1 1|S|  DS Codepoint | Stack
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

Type 4 = AS specific header extender:
	This label type can be used to arbitrarily colour, mark or differentiate
packets on a per AS basis. It creates the capability to extend (as many
times as desired) the Layer-3 header in an arbitrary manner.
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
  |              AS specific              |1 0 1|S|  AS Specific  | Stack
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

Type 5 = Reserved:
	This label type is reserved for future definition.
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
  |                reserved               |1 1 1|S|    reserved   | Stack
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

---------------------------------------------------------------------------

Secondary Proposal:
	These label encodings can be made more human readable and intuitive (an
issue that should not be dismissed lightly considering the needs of live
debug analysis, human configuration requirements and potential keying errors
etc) if the bits are rearranged as follows:

Type 1 = VPN identifier:
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
  |S|0|                       VPN Identifier                      | Stack
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

Type 2 = IP-FEC label (original):
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
  |S|1 0 0|                Label                  |      TTL      | 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

Type 3 = ER-TE label (diffserv):
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
  |S|1 0 1|                Label                  |  DS CodePoint | 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

Type 4 = AS specific header extender:
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
  |S|1 1 0|                    AS Specific Encoding               | 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

Type 5 = Reserved:
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
  |S|1 1 1|                          Reserved                     | 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

---------------------------------------------------------------------------

Conclusion:
	The proposed extensions to the MPLS label stack encoding provide a simple
and clean solution that delivers (effectively) full compatibility with the
existing label encoding, provides explicit support for traffic engineered
architectures, supports a sufficiently large private network identification
field, permits AS specific packet differentiation and allows for future
extensibility. Although the second proposal aims to rearrange bits in the
header (normally the Author would agree that this is an impossible request,
however the MPLS label stack encoding is sufficiently new and the changes
are simply structural changes that in this case it may be justified) the
benefits may outweigh the preference to leave them as defined. It is
envisioned that most HW/SW implementations should be handle either
structural definition with little change. It is important to note however
that the second proposal is not required to be implemented in order to
support all of the proposed extended features.

---------------------------------------------------------------------------

Feedback is welcomed,
-- 
Michael Stefan Cox                              Switch: +61 2 9699 0044
Principal  Engineer               V            Direct:  +61 2 9690 5295
Networks and Systems        A L C A T E L     Fax:      +61 2 9690 5247
Design  and  Strategy                        Mobile:    +61 418 226 108
mailto:[email-masked]   surfto:<http://www.alcatel.com.au/>

---

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Fri, 24 Sep 1999 10:11:22 -0400

> the industry to define a label encoding that falls short of its unique
.....
>                 EXP = xx0, Label Type 1 : VPN Identifier.

  Michael,

  You have obviously given some serious thought to these issues but I think you
are missing one important piece of the picture. This may help.

  One thing to keep in mind is that in a path oriented routing system the headers
are not self describing. That is, you cannot tell exactly what to do with the packet
simply from the header. There is context that is associated with the connection that
was created during the setup phase, which was remembered (hopefully permanently ;)
and which can be referenced during switching/forwarding operations. 

  For example, if we establish an LSP using say VCI for the primary label and
then a shim for the second label, and if that second label is to correspond to a
VPN of some kind, then since WE allocated the second label for that purpose, WE know it
is to be used for a VPN, which VPN etc. So, when we terminate the AAL5 ATM part
of the path, then do the second label lookup, the entry in our table tells us all 
about the VPN, what we are to do with it etc. There is no ambiguity.

  The other issue is that the EXP bits are almost certainly going to be used for
some kind of mapping to allow different per hop behaviors for packets in the 
same LSP. Something which is unfortunately lacking in ATM. I know this goes against
the idea of not being self describing but in this case the benefits of not having
to allocate multiple identically routed connections outweighs the slight violation
of the concept.

  I hope I have interpreted your suggestions correctly and that my answers help 
clarify things for you.

  Peter Ashwood-Smith

---

From: Michael Stefan Cox <[email-masked]>
Date: Thu, 30 Sep 1999 00:29:45 +1000

Peter,
	I am glad to see you agree with my fundamental conclusions.

The proposed alternative label stack encoding provides improved semantics to
aid in traffic analysis, debugging and fault identification. It maximises
the bit field utilisation and provides an optimal encoding in support of
Differentiated Services Codepoints and Layer-3 address extension. It
simultaneousely supports a path oriented system (with extended state
maintained in every intermediate node) and connectionless systems (state
required only at the edge nodes) with self describing headers for multiple
CoS per LSP and VPNs. And all without suffering any of the limitations of
ATM technologies oand avoiding enourmous complexities that arise when trying
to map 8 bit DS codepoints into 3 bit EXP fields and vice-versa.

> and which can be referenced during switching/forwarding operations.

This has be catered for via the Type 2 label.

I was aware of this fact.

> about the VPN, what we are to do with it etc. There is no ambiguity.

This has be catered for via the Type 1 label.

Alternatively a Type 4 label could be used if you desire the extended state
requirement in the edge nodes. The use of a Type 2 or 3 label would be
sub-optimal as the TTL or DS-Codepoint bits have no relevance.

> to allocate multiple identically routed connections outweighs the slight violation

This has been catered for by the Type 3 label.

As you have correctly noted, I have defined the EXP bits to allow
overloading of the TTL field to represent a complete DS Codepoint field for
implementing multiple CoS per LSP. This elegently side-steps the need to
define complex, and potentially incomplete mappings of 8 bit PHBs to 3 bit
PHBs and guarantees complete transparency and predictability when
implementing QoS on the Internet and within MPSL domains.

>   Peter Ashwood-Smith

The type 4 label is by far the most useful. This label enables advanced
solutions to several unresolved issues inherent within connectionless
networks.

regards,

---

From: Eric Gray <[email-masked]>
Date: Wed, 29 Sep 1999 13:06:14 -0400

Michael,

	It's always so amusing that someone is certain to
come along with a new floor plan right after the basement
has been poured. ;-)

	I believe the point is that you can do everything
you propose with the current labeling scheme.  Perhaps it
is not as elegant as it could be.  Perhaps it is not what
many of us would have wanted had we set out to design it 
in a vacuum.  Certainly we will uncover shortcomings in 
using it.  And perhaps the next version will be more like
you propose.

	But surely you don't expect people to seriously
consider scrapping the present encapsulation at this late
date, do you?

---

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Wed, 29 Sep 1999 13:40:21 -0400

>         I am glad to see you agree with my fundamental conclusions.

  I think you misunderstood me. I am of the opinion that a path oriented
routing
protocol should not bring higher layer information into its switching
headers.
ATM is the perfect example of this however the idea falls apart somewhat
when you
want to treat packets on the same flow differently. Hence the need for
different
behaviours being encoded in the headers. 

  However, I am not the person you have to convince. There are 500 of us
that
will be in Washington and you are more than welcome to present a draft
and
try to persuade everyone.  

  Cheers,

  Peter Ashwood-Smith

---

From: Michael Stefan Cox <[email-masked]>
Date: Thu, 30 Sep 1999 11:06:35 +1000

Eric,
	as you have noted, I do not seriousely expect people to immediately scrap
the present encapsulation. Rather I set out to do exactly what you have
identified below: To propose a label encoding mechanism that can be made
fully compatible with the present encapsulation and to demonstrate that it
can be made much more elegant with a minor redesign. Of course this was done
with the ultimate intention that future definitions may migrate towards it.

BTW the floor plan may have changed, but the basement is the same!
Firmware/Software would require trivial changes to support the bits in
different locations and I have not proposed any changes to the upper most
label when it is mapped onto existing protocol stacks such as ATM. I would
be _very_ surprised if any vendor has irrevocably committed themselves (via
fixed hardware) to reading the MPLS label stack bits as currently defined.
The proposed alternative encoding would allow vendors to go to market with
extremely powerful differentiators that permit new IP-MPLS services beyond
mapping an IP forwarding equivalence and explicit route traffic engineering.