случайная мысль
Подумалось мне тут, что семантика MPLS-метки довольно сильно перегружена. А именно.
1) Во-первых, и это очевидная и главная функция, метка выполняет роутинговую функцию - по метке происходит пересылка пакетов.
2) Метка также может выполнять функцию обозначения payload type. Например, MPLS'ный пакет с IPv4 внутри ничем, кроме метки, не отличается от, например, EoMPLS'ного пакета. Именно метка определяет каким именно образом обработает пакет egress LSR: какого типа будет lookup, будет ли он вообще и т.д. Или вот несколько более эзотерический пример: IPv4 explicit null и IPv6 explicit null - тут тип пейлоада кодируется напрямую.
3) В некоторых случаях метка может еще идентифицировать отправителя, вернее ingress LSR. Так, например, происходит в случае pseudowires - когда нам на egress LSR валится пакетик, мы достоверно знаем, кто его в MPLS-домен усунул. Это свойство pseudowires очень важно для реализации VPLS.
Когда есть такая семантическая перегруженность, чувства и опыт подсказывают, что здесь обязательно должны грабли. И действительно, необходимость в функции идентификации ingress LSR по метке привела к отвратительному разврату в виде label ranges в случае BGP-signalled VPLS или в виде полносвязной структуры targeted LDP сессий в случае LDP-signalled VPLS. А навешивание на метку функции идентификации payload type привело к грязному хаку типа нулевого control word в EoMPLS для избежания ECMP.
Пока все встреченные грабли вроде бы успешно объеханы. Однако интуиция говорит мне, что с главным западлом такого подхода мы еще только встретимся. Каково это западло на вид и в каком темном углу оно прячется, я не знаю. Поживем, увидим.
Upd: Я совсем забыл про L-LSP модель QoS'а. Это будет номер 4.
1) Во-первых, и это очевидная и главная функция, метка выполняет роутинговую функцию - по метке происходит пересылка пакетов.
2) Метка также может выполнять функцию обозначения payload type. Например, MPLS'ный пакет с IPv4 внутри ничем, кроме метки, не отличается от, например, EoMPLS'ного пакета. Именно метка определяет каким именно образом обработает пакет egress LSR: какого типа будет lookup, будет ли он вообще и т.д. Или вот несколько более эзотерический пример: IPv4 explicit null и IPv6 explicit null - тут тип пейлоада кодируется напрямую.
3) В некоторых случаях метка может еще идентифицировать отправителя, вернее ingress LSR. Так, например, происходит в случае pseudowires - когда нам на egress LSR валится пакетик, мы достоверно знаем, кто его в MPLS-домен усунул. Это свойство pseudowires очень важно для реализации VPLS.
Когда есть такая семантическая перегруженность, чувства и опыт подсказывают, что здесь обязательно должны грабли. И действительно, необходимость в функции идентификации ingress LSR по метке привела к отвратительному разврату в виде label ranges в случае BGP-signalled VPLS или в виде полносвязной структуры targeted LDP сессий в случае LDP-signalled VPLS. А навешивание на метку функции идентификации payload type привело к грязному хаку типа нулевого control word в EoMPLS для избежания ECMP.
Пока все встреченные грабли вроде бы успешно объеханы. Однако интуиция говорит мне, что с главным западлом такого подхода мы еще только встретимся. Каково это западло на вид и в каком темном углу оно прячется, я не знаю. Поживем, увидим.
Upd: Я совсем забыл про L-LSP модель QoS'а. Это будет номер 4.