draft-ietf-mpls-multicast-04.txt | draft-ietf-mpls-multicast-05.txt | |||
---|---|---|---|---|
Network Working Group D. Ooms, B. Sales | Network Working Group D. Ooms, B. Sales | |||
Internet Draft Alcatel | Internet Draft Alcatel | |||
Expiration Date: June 2001 W. Livens | Expiration Date: July 2001 W. Livens | |||
Colt Telecom | Colt Telecom | |||
A. Acharya | A. Acharya | |||
IBM | IBM | |||
F. Griffoul | F. Griffoul | |||
Ulticom | Ulticom | |||
F. Ansari | F. Ansari | |||
Bell Labs | Bell Labs | |||
December 2000 | January 2001 | |||
Framework for IP Multicast in MPLS | Framework for IP Multicast in MPLS | |||
draft-ietf-mpls-multicast-04.txt | draft-ietf-mpls-multicast-05.txt | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 2, line 17 | skipping to change at page 2, line 17 | |||
1. Introduction | 1. Introduction | |||
2. Layer 2 characteristics | 2. Layer 2 characteristics | |||
3. Taxonomy of IP multicast routing protocols in the context of MPLS | 3. Taxonomy of IP multicast routing protocols in the context of MPLS | |||
3.1. Aggregation | 3.1. Aggregation | |||
3.2. Flood & Prune | 3.2. Flood & Prune | |||
3.3. Source/Shared trees | 3.3. Source/Shared trees | |||
3.4. Co-existence of Source and Shared Trees | 3.4. Co-existence of Source and Shared Trees | |||
3.5. Uni/Bi-directional Shared Trees | 3.5. Uni/Bi-directional Shared Trees | |||
3.6. Encapsulated multicast data | 3.6. Encapsulated multicast data | |||
3.7. Loop-free-ness | 3.7. Loop-free-ness | |||
3.8. RPF Check | 3.8. Mapping of characteristics on existing protocols | |||
3.9. Mapping of characteristics on existing protocols | ||||
4. Mixed L2/L3 forwarding in a single node | 4. Mixed L2/L3 forwarding in a single node | |||
5. Taxonomy of IP multicast LSP triggers | 5. Taxonomy of IP multicast LSP triggers | |||
5.1. Request driven | 5.1. Request driven | |||
5.1.1. General | 5.1.1. General | |||
5.1.2. Multicast routing messages | 5.1.2. Multicast routing messages | |||
5.1.3. Resource reservation messages | 5.1.3. Resource reservation messages | |||
5.2. Topology driven | 5.2. Topology driven | |||
5.3. Traffic driven | 5.3. Traffic driven | |||
5.3.1. General | 5.3.1. General | |||
5.3.2. An implementation example | 5.3.2. An implementation example | |||
skipping to change at page 3, line 24 | skipping to change at page 3, line 23 | |||
LSR Label Switching Router | LSR Label Switching Router | |||
LSRd Downstream LSR | LSRd Downstream LSR | |||
LSRu Upstream LSR | LSRu Upstream LSR | |||
MOSPF Multicast OSPF | MOSPF Multicast OSPF | |||
mp2mp multipoint-to-multipoint | mp2mp multipoint-to-multipoint | |||
p2mp point-to-multipoint | p2mp point-to-multipoint | |||
PIM-DM Protocol Independent Multicast-Dense Mode | PIM-DM Protocol Independent Multicast-Dense Mode | |||
PIM-SM Protocol Independent Multicast-Sparse Mode | PIM-SM Protocol Independent Multicast-Sparse Mode | |||
QoS Quality of Service | QoS Quality of Service | |||
RP Rendezvous Point | RP Rendezvous Point | |||
RPF Reverse Path Forwarding | RPT-bit RP Tree bit [DEER] | |||
RSVP Resource reSerVation Protocol | RSVP Resource reSerVation Protocol | |||
SPT-bit Shortest Path Tree [DEER] | ||||
SSM Source Specific Multicast | SSM Source Specific Multicast | |||
TCP Transmission Control Protocol | TCP Transmission Control Protocol | |||
UDP User Datagram Protocol | UDP User Datagram Protocol | |||
VC Virtual Circuit | VC Virtual Circuit | |||
VCI Virtual Circuit Identifier | VCI Virtual Circuit Identifier | |||
VP Virtual Path | VP Virtual Path | |||
VPI Virtual Path Identifier | VPI Virtual Path Identifier | |||
Changes - clean up references - changes to section of Explicit | ||||
Routing - added SSM to multicast protocol taxonomy | ||||
1. Introduction | 1. Introduction | |||
In an MPLS cloud the routes are determined by a L3 routing protocol. | In an MPLS cloud the routes are determined by a L3 routing protocol. | |||
These routes can then be mapped onto L2 paths to enhance network | These routes can then be mapped onto L2 paths to enhance network | |||
performance. Besides this, MPLS offers a vehicle for enhanced | performance. Besides this, MPLS offers a vehicle for enhanced | |||
network services such as QoS/CoS, traffic engineering, etc. | network services such as QoS/CoS, traffic engineering, etc. | |||
Current unicast routing protocols generate a same (optimal) shortest | Current unicast routing protocols generate a same (optimal) shortest | |||
path in steady state for a certain (source, destination)-pair. Remark | path in steady state for a certain (source, destination)-pair. Remark | |||
that unicast protocols can behave slightly different with regard to | that unicast protocols can behave slightly different with regard to | |||
skipping to change at page 5, line 17 | skipping to change at page 5, line 15 | |||
Following characteristics are considered: | Following characteristics are considered: | |||
- Aggregation | - Aggregation | |||
- Flood & Prune | - Flood & Prune | |||
- Source/Shared trees | - Source/Shared trees | |||
- Co-existence of Source and Shared Trees | - Co-existence of Source and Shared Trees | |||
- Uni/Bi-directional shared trees | - Uni/Bi-directional shared trees | |||
- Encapsulated multicast data | - Encapsulated multicast data | |||
- Loop-free-ness | - Loop-free-ness | |||
- RPF check | ||||
The discussion of these characteristics will not lead to the | The discussion of these characteristics will not lead to the | |||
selection of one superior multicast routing protocol. It is not | selection of one superior multicast routing protocol. It is not | |||
impossible that different IP multicast routing protocols will be | impossible that different IP multicast routing protocols will be | |||
deployed in the Internet. | deployed in the Internet. | |||
3.1. Aggregation | 3.1. Aggregation | |||
In unicast different destination addresses are aggregated to one | In unicast different destination addresses are aggregated to one | |||
entry in the routing table, yielding one FEC and one LSP. | entry in the routing table, yielding one FEC and one LSP. | |||
skipping to change at page 11, line 38 | skipping to change at page 11, line 25 | |||
Multicast routing protocols which depend on a unicast routing | Multicast routing protocols which depend on a unicast routing | |||
protocol suffer from the same transient loops as the unicast | protocol suffer from the same transient loops as the unicast | |||
protocols do, however the effect of loops will be much worse in the | protocols do, however the effect of loops will be much worse in the | |||
case of multicast. The reason being, each time a multicast packet | case of multicast. The reason being, each time a multicast packet | |||
goes around a loop, copies of the packet may be emitted from the loop | goes around a loop, copies of the packet may be emitted from the loop | |||
if branches exist in the loop. | if branches exist in the loop. | |||
Currently loop detection is a configurable option in LDP and a | Currently loop detection is a configurable option in LDP and a | |||
decision on the mechanism for loop prevention is postponed. | decision on the mechanism for loop prevention is postponed. | |||
3.8. RPF Check | 3.8. Mapping of characteristics on existing protocols | |||
Some protocols perform a Reverse Path Forwarding (RPF) check on the | ||||
received multicast packets. This mechanism checks whether the packet | ||||
is received on the interface which is on the shortest path to the | ||||
source (or root). This mechanism can introduce problems when | ||||
explicit routing is used (see section 7). Indeed, explicit routing | ||||
can construct a tree yielding another incoming interface than the | ||||
RPF-compatible one. | ||||
3.9. Mapping of characteristics on existing protocols | ||||
The above characteristics are summarized in Table 1 for a non- | The above characteristics are summarized in Table 1 for a non- | |||
exhaustive list of existing IP multicast routing protocols: DVMRP | exhaustive list of existing IP multicast routing protocols: DVMRP | |||
[PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [DEER], PIM-SM [DEE2], SSM | [PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [DEER], PIM-SM [DEE2], SSM | |||
[HOLB], SM [PERL]. | [HOLB], SM [PERL]. | |||
+------------------+------+------+------+------+------+------+------+ | +------------------+------+------+------+------+------+------+------+ | |||
| |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM | | | |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM | | |||
+------------------+------+------+------+------+------+------+------+ | +------------------+------+------+------+------+------+------+------+ | |||
|Aggregation |no |no |no |no |no |no |no | | |Aggregation |no |no |no |no |no |no |no | | |||
+------------------+------+------+------+------+------+------+------+ | +------------------+------+------+------+------+------+------+------+ | |||
skipping to change at page 12, line 26 | skipping to change at page 12, line 4 | |||
|Tree Type |source|source|shared|source|both |source|shared| | |Tree Type |source|source|shared|source|both |source|shared| | |||
+------------------+------+------+------+------+------+------+------+ | +------------------+------+------+------+------+------+------+------+ | |||
|State Co-existence|no |no |no |no |yes |no |no | | |State Co-existence|no |no |no |no |yes |no |no | | |||
+------------------+------+------+------+------+------+------+------+ | +------------------+------+------+------+------+------+------+------+ | |||
|Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi | | |Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi | | |||
+------------------+------+------+------+------+------+------+------+ | +------------------+------+------+------+------+------+------+------+ | |||
|Encapsulation |no |no |yes |no |yes |no |yes | | |Encapsulation |no |no |yes |no |yes |no |yes | | |||
+------------------+------+------+------+------+------+------+------+ | +------------------+------+------+------+------+------+------+------+ | |||
|Loop Free |no |no |no |no |no |no |no | | |Loop Free |no |no |no |no |no |no |no | | |||
+------------------+------+------+------+------+------+------+------+ | +------------------+------+------+------+------+------+------+------+ | |||
|RPF check |yes |yes |no |yes |yes |yes |no | | ||||
+------------------+------+------+------+------+------+------+------+ | ||||
Table 1. Taxonomy of IP Multicast Routing Protocols | Table 1. Taxonomy of IP Multicast Routing Protocols | |||
From Table 1 one can derive e.g. that DVMRP will consume a lot of | From Table 1 one can derive e.g. that DVMRP will consume a lot of | |||
labels when the Flood & Prune L3 tree is mapped onto a L2 tree. | labels when the Flood & Prune L3 tree is mapped onto a L2 tree. | |||
Furthermore since DVMRP uses source trees it experiences no merging | Furthermore since DVMRP uses source trees it experiences no merging | |||
problem when label switching is applied. The table can be | problem when label switching is applied. The table can be | |||
interpreted in the same way for the other protocols. | interpreted in the same way for the other protocols. | |||
4. Mixed L2/L3 forwarding in a single node | 4. Mixed L2/L3 forwarding in a single node | |||
skipping to change at page 14, line 6 | skipping to change at page 13, line 16 | |||
Table. | Table. | |||
Although the mixed L2/L3 forwarding requires processing of the | Although the mixed L2/L3 forwarding requires processing of the | |||
traffic at L3, the load on the L3 forwarding engine is generally less | traffic at L3, the load on the L3 forwarding engine is generally less | |||
than in a pure L3 node. | than in a pure L3 node. | |||
Supporting this 'mixed L2/L3 forwarding' feature has following | Supporting this 'mixed L2/L3 forwarding' feature has following | |||
advantages: | advantages: | |||
a) Assume LSR A (Figure 8) is an MPLS edge node for the branch | a) Assume LSR A (Figure 8) is an MPLS edge node for the branch | |||
towards LSR B and an MPLS root node for the branch towards LSR C. | towards LSR B and an MPLS core node for the branch towards LSR C. | |||
The mixed L2/L3 forwarding allows that the branch towards C is not | The mixed L2/L3 forwarding allows that the branch towards C is not | |||
disturbed by a return to L3 in LSR A. | disturbed by a return to L3 in LSR A. | |||
+-------------+ | +-------------+ | |||
| MPLS cloud | | | MPLS cloud | | |||
| N | | | N | | |||
| / \ | | | / \ | | |||
| / \ | | | / \ | | |||
| / \ | | | / \ | | |||
| A N | | | A N | | |||
skipping to change at page 20, line 35 | skipping to change at page 20, line 18 | |||
Piggybacking is just one possible component of an MPLS multicast | Piggybacking is just one possible component of an MPLS multicast | |||
solution. | solution. | |||
7. Explicit routing | 7. Explicit routing | |||
Explicit routing for unicast refers to overriding the unicast routing | Explicit routing for unicast refers to overriding the unicast routing | |||
table by using LSPs. | table by using LSPs. | |||
A first way to interpret "multicast explicit routing" is overriding | A first way to interpret "multicast explicit routing" is overriding | |||
the tree established by the multicast routing protocol by another LSP | the tree established by the multicast routing protocol by another LSP | |||
tree (e.g. a centrally calculated Steiner tree). In this | tree (e.g. a Steiner tree calculated by an offline tool). In this | |||
interpretation the current 'shortest path' multicast routing protocol | interpretation the current 'shortest path' multicast routing protocol | |||
becomes obsolete and can be replaced by label advertisement messages | becomes obsolete and can be replaced by label advertisement messages | |||
that follow an explicit route which is e.g. calculated by an offline | that follow an explicit route (e.g. a branch of the Steiner tree). | |||
tool. | ||||
A second way of interpreting "multicast explicit routing" is that | A second way of interpreting "multicast explicit routing" is that the | |||
multicast routing protocols use the explicit unicast routes to | known multicast routing protocols are running, but that the messages | |||
construct trees. This approach requires that the RPF check also | generated by these protocols use explicit unicast routes (instead of | |||
takes the explicit path into account. | the IGP shortest path routes) to construct trees. | |||
8. QoS/CoS | 8. QoS/CoS | |||
8.1. DiffServ | 8.1. DiffServ | |||
The Differentiated Services approach can be applied to multicast as | The Differentiated Services approach can be applied to multicast as | |||
well. It introduces finer stream granularities (DiffServ Codepoint | well. It introduces finer stream granularities (DiffServ Codepoint | |||
(DSCP) as an extra differentiator). A sender can construct one or | (DSCP) as an extra differentiator). A sender can construct one or | |||
more trees with different DSCPs. | more trees with different DSCPs. | |||
These (S, G, DSCP) or (*, G, DSCP) trees can be mapped very easily | These (S, G, DSCP) or (*, G, DSCP) trees can be mapped very easily | |||
onto LSPs when the traffic driven trigger is used. In this case one | onto LSPs when the traffic driven trigger is used. In this case one | |||
can create LSPs with different attributes for the various DSCPs. | can create LSPs with different attributes for the various DSCPs. | |||
Note however that these LSPs still use the same route as long as the | Note however that these LSPs still use the same route as long as the | |||
tree construction mechanism itself does not take the DSCP as an | tree construction mechanism itself does not take the DSCP as an | |||
skipping to change at page 22, line 13 | skipping to change at page 21, line 41 | |||
1) Each LSR on the multi-access link memorizes all the advertised | 1) Each LSR on the multi-access link memorizes all the advertised | |||
labels on the link, even if it has not received a join for the | labels on the link, even if it has not received a join for the | |||
associated group. If an LSR is added to the multi-access link it has | associated group. If an LSR is added to the multi-access link it has | |||
to retrieve this information from another LSR on the link or in case | to retrieve this information from another LSR on the link or in case | |||
of soft state label advertisement it can wait a certain time before | of soft state label advertisement it can wait a certain time before | |||
it can allocate labels itself. If LSRs allocate a label 'at the same | it can allocate labels itself. If LSRs allocate a label 'at the same | |||
moment' the LSR with the highest IP address could keep it, while the | moment' the LSR with the highest IP address could keep it, while the | |||
other LSRs withdraw the label. | other LSRs withdraw the label. | |||
2) Each LSR gets its own label range to allocate labels from. A | 2) Each LSR gets its own label range to allocate labels from. A | |||
mechanism for label partitioning is described in [FAR2]. If an LSR | mechanism for label partitioning is described in [FARI]. If an LSR | |||
is added to the multi-access link the label ranges have to be | is added to the multi-access link the label ranges have to be | |||
negotiated again and possibly existing LSPs are teared down and are | negotiated again and possibly existing LSPs are teared down and are | |||
reconstructed with other labels. | reconstructed with other labels. | |||
3) Per multi-access link one LSR could be elected to be responsible | 3) Per multi-access link one LSR could be elected to be responsible | |||
for label allocation. When an LSR needs a label, it can request it | for label allocation. When an LSR needs a label, it can request it | |||
from this Label Allocation LSR. | from this Label Allocation LSR. | |||
Unlike the unicast case, a multicast stream can have more than one | Unlike the unicast case, a multicast stream can have more than one | |||
downstream LSR which all have to use the same label. Two solutions | downstream LSR which all have to use the same label. Two solutions | |||
skipping to change at page 26, line 38 | skipping to change at page 26, line 22 | |||
References | References | |||
[ACHA] A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast ATM | [ACHA] A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast ATM | |||
Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE | Cell Transport (IPSOFACTO) : Switching Multicast flows", IEEE | |||
Globecom '97. | Globecom '97. | |||
[AWDU] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow and V. Sriniva- | [AWDU] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow and V. Sriniva- | |||
san, "Extensions to RSVP for LSP Tunnels", Work In Progress | san, "Extensions to RSVP for LSP Tunnels", Work In Progress | |||
[ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas, | [ANDE] L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas, | |||
"Label Distribution Protocol", Work In Progress. | "LDP specification", RFC3036, January 2001. | |||
[BALL] A. Ballardie, "Core Based Trees (CBT) Multicast Routing Archi- | [BALL] A. Ballardie, "Core Based Trees (CBT) Multicast Routing Archi- | |||
tecture", RFC2201, September 1997. | tecture", RFC2201, September 1997. | |||
[CALL] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A. | ||||
Viswanathan, "A Framework for Multiprotocol Label Switching", | ||||
Work In Progress. | ||||
[CONT] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame | [CONT] A. Conta, P. Doolan, A. Malis, "Use of Label Switching on Frame | |||
Relay Networks", Work In Progress. | Relay Networks", RFC3034, January 2001. | |||
[CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden | [CRAW] E. Crawley, Editor, L. Berger, S. Berson, F. Baker, M. Borden | |||
and J. Krawczyk, "A Framework for Integrated Services and RSVP | and J. Krawczyk, "A Framework for Integrated Services and RSVP | |||
over ATM", RFC2382, August 1998. | over ATM", RFC2382, August 1998. | |||
[DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. | [DAVI] B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. | |||
Swallow and P. Doolan, "MPLS using ATM VC switching", Work In | Swallow and P. Doolan, "MPLS using LDP and ATM VC switching", | |||
Progress. | RFC3035, January 2001. | |||
[DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. | [DEER] S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. | |||
Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei, | Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma and L Wei, | |||
"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol | "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol | |||
Specification", RFC 2117, June 1997. | Specification", RFC 2117, June 1997. | |||
[DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol | [DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, Protocol | |||
Independent Multicast Version 2 Dense Mode Specification", Work | Independent Multicast Version 2 Dense Mode Specification", Work | |||
In Progress. | In Progress. | |||
[FARI] D. Farinacci, Y. Rekhter and E. Rosen, "Using PIM to Distribute | [FARI] D. Farinacci, Y. Rekhter and E. Rosen, "Using PIM to Distribute | |||
MPLS Labels for Multicast Routes", Work In Progress. | MPLS Labels for Multicast Routes", Work In Progress. | |||
[FAR2] D. Farinacci and Y. Rekhter, "Partitioning Label Space among | ||||
Multicast Routers on a Common Subnet", Work In Progress. | ||||
[FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version | [FENN] W. Fenner, "Internet Group Management Protocol, IGMP, version | |||
2", RFC 2236, November 1997. | 2", RFC 2236, November 1997. | |||
[GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load | [GARR] M. Garrett and M. Borden, "Interoperation of Controlled-Load | |||
Service and Guaranteed Service with ATM", RFC2381, August 1998. | Service and Guaranteed Service with ATM", RFC2381, August 1998. | |||
[HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work | [HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work | |||
In Progress. | In Progress. | |||
[MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994. | [MOY] J. Moy, "Multicast extensions to OSPF", RFC 1584, March 1994. | |||
[NAGA] K. Nagami, N. Demizu, H. Esaki, Y. Katsube and P. Doolan, "VCID | [NAGA] K. Nagami, N. Demizu, H. Esaki, Y. Katsube and P. Doolan, "VCID | |||
Notification over ATM link for LDP", Work In Progress. | Notification over ATM link for LDP", RFC3038, January 2001. | |||
[PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. | [PERL] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. | |||
Maufer, "Simple Multicast", Work In Progress. | Maufer, "Simple Multicast", Work In Progress. | |||
[PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work | [PUSA] T. Pusateri, "Distance Vector Multicast Routing Protocol", Work | |||
In Progress. | In Progress. | |||
[PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", | [PAXS] V. Paxson, "End-to-End Routing Behavior in the Internet", | |||
IEEE/ACM Transactions on Networking 5(5), pp. 601-615. | IEEE/ACM Transactions on Networking 5(5), pp. 601-615. | |||
[ROSE] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T. | [ROSE] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T. | |||
Li, A. Conta, "MPLS Label Stack Encoding", Work In Progress. | Li, A. Conta, "MPLS Label Stack Encoding", RFC3032, January | |||
2001. | ||||
Authors Addresses | Authors Addresses | |||
Dirk Ooms | Dirk Ooms | |||
Alcatel Corporate Research Center | Alcatel Corporate Research Center | |||
Fr. Wellesplein 1, 2018 Antwerpen, Belgium. | Fr. Wellesplein 1, 2018 Antwerp, Belgium. | |||
Phone : 32 3 2404732 | Phone : 32 3 2404732 | |||
Fax : 32 3 2409879 | Fax : 32 3 2409879 | |||
E-mail: Dirk.Ooms@alcatel.be | E-mail: Dirk.Ooms@alcatel.be | |||
Bernard Sales | Bernard Sales | |||
Alcatel Corporate Research Center | Alcatel Corporate Research Center | |||
Fr. Wellesplein 1, 2018 Antwerpen, Belgium. | Fr. Wellesplein 1, 2018 Antwerp, Belgium. | |||
Phone : 32 3 2409574 | Phone : 32 3 2409574 | |||
E-mail: Bernard.Sales@alcatel.be | E-mail: Bernard.Sales@alcatel.be | |||
Wim Livens | Wim Livens | |||
Colt Telecom | Colt Telecom | |||
Zweefvliegtuigstraat 10, 1130 Brussel, Belgium | Zweefvliegtuigstraat 10, 1130 Brussels, Belgium | |||
Phone : 32 2 7901705 | Phone : 32 2 7901705 | |||
Fax : 32 2 7901711 | Fax : 32 2 7901711 | |||
E-mail: WLivens@colt-telecom.be | E-mail: WLivens@colt-telecom.be | |||
Arup Acharya | Arup Acharya | |||
IBM TJ Watson Research Center | IBM TJ Watson Research Center | |||
30 Saw Mill River Road, Hawthorne | 30 Saw Mill River Road, Hawthorne | |||
NY 10532 | NY 10532 | |||
Phone : 1 914 784 7481 | Phone : 1 914 784 7481 | |||
E-mail: arup@us.ibm.com | E-mail: arup@us.ibm.com | |||
Frederic Griffoul | Frederic Griffoul | |||
Ulticom, Inc. | Ulticom, Inc. | |||
Les Algorithmes, 2000 Route des Lucioles, BP29 | Les Algorithmes, 2000 Route des Lucioles, BP29 | |||
skipping to change at page 28, line 48 | skipping to change at page 28, line 22 | |||
Ulticom, Inc. | Ulticom, Inc. | |||
Les Algorithmes, 2000 Route des Lucioles, BP29 | Les Algorithmes, 2000 Route des Lucioles, BP29 | |||
06901 Sophia-Antipolis, FRANCE | 06901 Sophia-Antipolis, FRANCE | |||
E-mail: griffoul@ulticom.com | E-mail: griffoul@ulticom.com | |||
Furquan Ansari | Furquan Ansari | |||
Bell Labs | Bell Labs | |||
101 Crawfords Corner Rd., Holmdel, NJ 07733 | 101 Crawfords Corner Rd., Holmdel, NJ 07733 | |||
Phone : 1 732 949 5149 | Phone : 1 732 949 5149 | |||
Fax : 1 732 332 6511 | Fax : 1 732 332 6511 | |||
E-mail: furquan@dnrc.bell-labs.comy | E-mail: furquan@dnrc.bell-labs.com | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |