Berkrley Internet Name Domain. Иногда для этой цели выделяют специальную машину задача

Вид материалаЗадача

Содержание


4.  Процедуры пересылки меток (Hop-by-Hop)
Подобный материал:
1   ...   51   52   53   54   55   56   57   58   59
4.  Процедуры пересылки меток (Hop-by-Hop)

В этом разделе, мы рассматриваем только ассоциации меток, которые используются для трафика, который коммутируется по меткам в пределах пути, маршрутизованного по схеме шаг-за-шагом. В этих случаях, метка будет соответствовать адресному префиксу в маршрутной таблице.
4.1.  Процедуры анонсирования и использования меток

Существует некоторое число различных процедур, которые могут использоваться для рассылки ассоциаций меток. Некоторые исполняются нижестоящим LSR, а некоторые вышестоящим LSR. Нижестоящий LSR должен выполнить:

-  Процедуру рассылки и
- Процедуру отзыва.

Вышестоящий LSR должен выполнить:
-  Процедуру Request и
-  Процедуру NotAvailable и
-  Процедуру Release и
-  Процедуру labelUse.

Архитектура MPLS поддерживает несколько разных вариантов каждой процедуры. Однако архитектура MPLS не поддерживает все комбинации возможных вариантов. Набор поддерживаемых комбинаций будет обсужден в разделе 4.2, где рассматривается совместимость различных комбинаций.
4.1.1.  Нижестоящий LSR: Процедура рассылки

Процедура рассылки используется нижестоящим LSR, чтобы определить, когда он должен разослать своим партнерам ассоциации меток для конкретного адресного префикса. Архитектура поддерживает четыре разные процедуры рассылки.

Вне зависимости от используемой процедуры рассылки, если ассоциация метки для заданного адресного префикса была послана нижестоящим LSR Rd вышестоящему LSR Ru, и, если в какой-то момент атрибуты ассоциации (как это определено выше) изменились, тогда Rd должен проинформировать Ru о новых атрибутах.

Если LSR поддерживает несколько маршрутов для заданного адресного префикса, то будет ли LSR ассоциировать несколько меток данному адресному префиксу (один на маршрут), и, следовательно, рассылать несколько ассоциаций, является исключительно локальной проблемой
4.1.1.1.  PushUnconditional

Пусть Rd является LSR. Предположим, что:

1. X является адресным префиксом в маршрутной таблице Rd

2. Ru является партнером по рассылке меток Rd с точки зрения X

Когда бы эти условия ни выполнялись, Rd должен связать метку с X и послать эту ассоциацию Ru. Отслеживание ассоциаций, которые посылаются Ru, и контроль того, что Ru всегда имеет эти ассоциации, является областью ответственности Rd.

Эта процедура должна использоваться LSR, которые выполняют не затребованное присвоение меток в независимом режиме управления LSP.
4.1.1.2.  PushConditional

Пусть Rd является LSR. Предположим, что:

1. X является адресным префиксом в маршрутной таблице Rd

2. Ru является партнером Rd по рассылке меток с учетом X

3. Rd является либо концом LSP, либо прокси концом LSP для X , или следующим шагом Rd L3 для X является Rn, где Rn отличается от Ru, и Rn связал метку с X и послал эту ассоциацию Rd.

Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru.

Поскольку PushUnconditional вызывает рассылку ассоциаций меток всем адресным префиксам маршрутной таблицы, PushConditional вызывает рассылку ассоциаций меток только тем адресным префиксам, для которых получены ассоциации от одного следующего шага LSP, или для которых не существует следующего шага с поддержкой MPLS L3.

Эта процедуру следует использовать LSR, которые выполняют не затребованное присвоение меток в упорядоченном режиме управления LSP.
4.1.1.3.  PulledUnconditional

Пусть Rd является LSR. Предположим, что:

1. X является адресным префиксом в маршрутной таблице Rd
2. Ru является партнером Rd по рассылке меток с учетом X

3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru

Затем Rd должен связать метку с X и послать эту ассоциацию Ru. Заметим, что если X отсутствует в маршрутной таблице Rd, или если Rd не является партнером Ru по рассылке меток с учетом X, тогда Rd должен проинформировать Ru о том, что в данный момент не может предоставить ассоциацию.

Если Rd уже переслал Ru ассоциацию метки для адресного префикса X, и получил новый запрос от Ru ассоциации для адресного префикса X, он свяжет вторую метку, и пошлет новую ассоциацию Ru . Первая ассоциация метки остается в силе.

Эта процедура будет использоваться LSR, выполняющими рассылку меток downstream-on-demand, используя независимый режим управления LSP.
4.1.1.4.  PulledConditional

Пусть Rd является LSR. Предположим, что:

1. X является адресным префиксом в маршрутной таблице Rd
2. Ru является партнером Rd по рассылке меток с учетом X
3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru
4. Rd является либо концом LSP, либо прокси концом LSP для X, или следующим шагом Rd L3 для X является Rn, где Rn отличается от Ru, а Rn связал метку с X и послал эту ассоциацию Rd

Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru . Заметим, что если X отсутствует в маршрутной таблице Rd, а получить ассоциацию для X через следующий шаг Rd для X невозможно, или если Rd не является партнером Ru по пересылке меток с учетом X, тогда Rd должен проинформировать Ru, что не может в данный момент предоставить ему необходимую ассоциацию.

Однако, если хотя бы одно условие не выполнено, Rn не выдает метку Rd, а Rd должен отложить отклик для Ru до тех пор, пока Rn не пришлет ассоциацию метки.

Если Rd послал Ru ассоциацию метки для адресного префикса X, а спустя какое-то время любой из атрибутов ассоциации метки изменился, Rd должен заново послать Ru ассоциацию с новым значением атрибута. Он должен сделать это даже если Ru не послал нового запроса. Эту процедуру следует использовать LSR, которые осуществляют ассоциацию меток downstream-on-demand в упорядоченном режиме управления LSP.

В разделе 4.2, мы обсудим то, как выбрать конкретную процедуру, которую следует использовать в конкретной ситуации, и как гарантировать совместимость работы LSR, выбравших разные процедуры.