File: rfc3037.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (395 lines) | stat: -rw-r--r-- 13,601 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395






Network Working Group                                          B. Thomas
Request for Comments: 3037                           Cisco Systems, Inc.
Category: Informational                                          E. Gray
                                                           Zaffire, Inc.
                                                            January 2001


                           LDP Applicability

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   Multiprotocol Label Switching (MPLS) is a method for forwarding
   packets that uses short, fixed-length values carried by packets,
   called labels, to determine packet nexthops.  A fundamental concept
   in MPLS is that two Label Switching Routers (LSRs) must agree on the
   meaning of the labels used to forward traffic between and through
   them.  This common understanding is achieved by using a set of
   procedures, called a label distribution protocol, by which one LSR
   informs another of label bindings it has made.  This document
   describes the applicability of a set of such procedures called LDP
   (for Label Distribution Protocol) by which LSRs distribute labels to
   support MPLS forwarding along normally routed paths.

1. LDP Applicability

   A label distribution protocol is a set of procedures by which one
   Label Switching Router (LSR) informs another of the meaning of labels
   used to forward traffic between and through them.

   The MPLS architecture allows for the possibility of more than a
   single method for distributing labels, and a number of different
   label distribution protocols are being standardized.  Existing
   protocols have been extended so that label distribution can be
   piggybacked on them, and new protocols have been defined for the
   explicit purpose of distributing labels.






Thomas & Gray                Informational                      [Page 1]

RFC 3037                   LDP Applicability                January 2001


   This document describes the applicability of the Label Distribution
   Protocol (LDP), a new protocol for label distribution designed to
   support label distribution for MPLS forwarding along normally routed
   paths as determined by destination-based routing protocols.  This is
   sometimes called MPLS hop-by-hop forwarding.

   LDP, together with an IP routing plane and software to program ATM
   switch or Frame Relay switch cross-connect tables, can implement IP
   in a network of ATM and/or Frame Relay switches without requiring an
   overlay or the use of ATM-specific or Frame Relay-specific addressing
   or routing.

   LDP is also useful in situations that require efficient hop-by-hop
   routed tunnels, such as MPLS-based VPN architectures [RFC2574] and
   tunneling between BGP border routers.

   In addition, LDP includes a mechanism that makes it possible to
   extend it to support MPLS features that go beyond best effort hop-
   by-hop forwarding.

   As a stand-alone protocol for distributing labels LDP does not rely
   on the presence of specific routing protocols at every hop along an
   LSP path in order to establish an LSP.  Hence LDP is useful in
   situations in which an LSP must traverse nodes which may not all
   support a common piggybacked approach to distributing labels.

   Traffic Engineering [TE] is expected to be an important MPLS
   application.  MPLS support for Traffic Engineering uses explicitly
   routed LSPs, which need not follow normally-routed (hop-by-hop)
   paths.

   Explicitly routed LSPs may be setup by CR-LDP [CRLDP-AS], a set of
   extensions to LDP, or by RSVP-TE [RSVP-TE-AS], a set of extensions to
   RSVP.  There is currently no consensus on which of these protocols is
   technically superior.  Therefore, network administrators should make
   a choice between the two based upon their needs and particular
   situation.

2. Requirement Level

   The "requirement level" [RFC2026] for LDP is:

      Implementation of LDP is recommended for devices that perform MPLS
      forwarding along normally routed paths as determined by
      destination-based routing protocols.






Thomas & Gray                Informational                      [Page 2]

RFC 3037                   LDP Applicability                January 2001


3. Feature Overview

   LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with
   each label it distributes.  Two LSRs which use LDP to exchange FEC-
   label binding information are known as "LDP Peers", and we speak of
   there being an "LDP Session" between them.

   LDP uses TCP for session communication.  Use of TCP ensures that
   session messages are reliably delivered, and that distributed labels
   and state information associated with LSPs need not be refreshed
   periodically.

   LDP includes a mechanism by which an LSR can discover potential LDP
   peers.  The discovery mechanism makes it unnecessary for operators to
   explicitly configure each LSR with its LDP peers.

   When an LSR discovers another LSR it follows the LDP session setup
   procedure to establish an LDP session.  By means of this procedure
   the LSRs establish a session TCP connection and use it to negotiate
   parameters for the session, such as the label distribution method to
   be used (see below).  After the LSRs agree on the parameters, the
   session is operational and the LSRs use the TCP connection for label
   distribution.

   LDP supports two different methods for label distribution.  An LSR
   using Downstream Unsolicited distribution advertises FEC-label
   bindings to its peers when it is ready to forward packets in the FEC
   by means of MPLS.  An LSR using Downstream on Demand distribution
   provides FEC-label bindings to a peer in response to specific
   requests from the peer for a label for the FEC.

   LDP allows LSRs flexibility in strategies for retaining learned
   labels.  An LSR using liberal label retention stores all labels
   learned from peers regardless of whether it currently needs them for
   forwarding, whereas one using conservative label retention stores
   only labels for which it has immediate use and releases unneeded
   labels to the peer that advertised them.

   In addition, LDP allows flexibility in strategies for when to
   advertise FEC-label bindings.  An LSR using independent control mode
   advertises FEC-label bindings to peers whenever it sees fit, whereas
   one using ordered control advertises bindings only when it has
   previously received a label for the FEC from the FEC nexthop or it is
   an MPLS egress for the FEC.

   Downstream on Demand distribution with conservative label retention
   and ordered control is appropriate in situations where labels are a
   relatively scarce resource that must be conserved, and Downstream



Thomas & Gray                Informational                      [Page 3]

RFC 3037                   LDP Applicability                January 2001


   Unsolicited distribution with liberal label retention and independent
   control is appropriate where labels are plentiful and need not be
   carefully conserved.  However, the protocol permits other
   combinations of distribution method, label retention mode and control
   mode, including hybrid variants of them.

   LDP defines a mechanism for loop detection to protect against
   forwarding loops in LSPs that traverse non-TTL MPLS clouds; see
   [RFC3031] for discussion of situations which may benefit from this
   mechanism.  The loop detection mechanism is optional in the sense
   that it may be disabled by LSR configuration.  However, an LDP-
   compliant LSR must implement it.

   LDP includes an extension mechanism which supports the development of
   vendor-private and experimental features.  This mechanism defines
   procedures for introducing new types of messages and TLVs, methods an
   LSR can use for detecting such messages and TLVs, and procedures an
   LSR must follow when it receives a message or TLV it does not
   implement.  While it is not possible to make every future enhancement
   backwards compatible, these procedures facilitate the introduction of
   new capabilities in MPLS networks that include older implementations
   that do not recognize them.

4. Scalability Considerations

   The following factors may influence the scalability of LDP
   implementations:

      -  LDP label distribution is incremental, requiring no periodic
         refresh of FEC-label bindings.

      -  In situations were label resources may be scarce (ATM and Frame
         Relay links) the use of the Downstream on Demand distribution
         method with conservative label retention ensures that only
         those labels required to support normally-routed paths are
         allocated and distributed.

      -  In situations where label resources are not scarce, the use of
         the Downstream Unsolicited method with liberal label retention
         ensures that changes in FEC nexthop from one LDP peer to
         another require no distribution action to update previously
         distributed labels.

      -  Limitations on the number of TCP connections an LSR supports
         limit the number of LDP peers the LSR can support.






Thomas & Gray                Informational                      [Page 4]

RFC 3037                   LDP Applicability                January 2001


      -  Use of the optional path vector based loop detection mechanism
         imposes additional memory and processing requirements on an
         LSR, as well as additional LDP traffic.  Both impact
         scalability.

5. Security Considerations

   LDP defines the optional use of the TCP MD5 Signature Option to
   protect against the introduction of spoofed TCP segments into LDP
   session connection streams.  LDP use of the TCP MD5 Signature Option
   is similar to BGP [RFC1771] use of the option specified in [RFC2385].

6. References

   [CRLDP-AS]   J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright,
                "Applicability Statement for CR-LDP", Work in Progress,
                September 1999.

   [RFC1771]    Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
                (BGP-4)", RFC 1771, March 1995.

   [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
                3", BCP 9, RFC 2026, October 1996.

   [RFC2385]    Heffernan, A., "Protection of BGP Sessions via the TCP
                MD5 Signature Option", RFC 2385, August 1998.

   [RFC2547]    Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
                March 1999.

   [RFC3036]    Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
                B. Thomas, "LDP Specification", RFC 3036, January 2001.

   [RFC3031]    Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
                Label Switching Architecture", RFC 3031, January 2001.

   [RSVP-TE-AS] Awduche, D., Hannan, A. and X. Xiao, "Applicability
                State for Extensions to RSVP for LSP-Tunnels", Work in
                Progress, April 2000.












Thomas & Gray                Informational                      [Page 5]

RFC 3037                   LDP Applicability                January 2001


7. Authors' Addresses

   Eric Gray
   Zaffire, Inc
   2630 Orchard Parkway,
   San Jose, CA 95134-2020

   Phone:  408-894-7362
   EMail: ewgray@mindspring.com


   Bob Thomas
   Cisco Systems, Inc.
   250 Apollo Dr.
   Chelmsford, MA 01824

   Phone:  978-244-8078
   EMail: rhthomas@cisco.com

































Thomas & Gray                Informational                      [Page 6]

RFC 3037                   LDP Applicability                January 2001


8. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Thomas & Gray                Informational                      [Page 7]