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/