Сети с множественным доступом
Мультикастный в сетях с множественным доступом представляет собой определенную проблему. LSR, который хочет присоединиться к группе, должен всегда быть готов воспринять метку, которая уже приписана группе LSP. Это может быть достигнуто тремя путями:
- Каждый LSR канала с множественным доступом запоминает все анонсированные метки канала, даже если он не получил сигнал join для соответствующей группы. Если LSR добавлен к каналу с множественным доступом, он должен получить эту информацию от другого LSR канала или в случае soft state анонсирования меток, он может ждать некоторое время, прежде чем сам сможет сформировать метку. Если LSR формируют метки в один и тот же момент, LSR с более высоким кодом IP-адреса может ее сохранить, в то время как другой LSR отзывает свою метку.
- Каждый LSR получает свой собственный диапазон меток. Механизм распределения меток описан в [FARI]. Если LSR добавляется к каналу с множественным доступом, диапазон меток должен быть согласован снова и, возможно, некоторые существующие каналы LSP разрываются и восстанавливаются с другими метками.
- В каждом канале с множественным доступом один LSR может быть выбран ответственным за выделение меток. Когда LSR нужна метка, он может запросить ее у этого LSR, осуществляющим присвоение меток.
В отличие от уникастного варианта, мультикастный поток может иметь более одного нижележащего LSR, которые все должны использовать одну и ту же метку. Можно обсуждать две схемы анонсирования меток:
- [FARI] предлагает рассылать анонсирования меток мультикастно всем LSR, подключенным к общему каналу. Так как мультикастинг не является надежным, это требует периодического анонсирования меток, что приведет повторным оповещениям об одних и тех же метках.
- Другой подход заключается в том, что LSR рассылает анонсирования меток уникастно с привлечением, например, протокола TCP всем другим (или всем заинтересованным) LSR, подключенным к общему каналу.
Так как LSP оправданы, если они живут долго, и так как число LSR в используемом совместно канале ограничено, второй подход представляется предпочтительным.
Другой момент, связанный с мультикастингом в сетях с множественным доступом, сопряжен с тем, следует ли использовать для присвоения меток вышестоящий или нижестоящий LSR. Для мультикастного трафика, использование вышестоящего LSR проще, так как там может быть только один вышестоящий узел, принадлежащий данному мультикастному дереву. Этот (вышестоящий) узел может присвоить уникальную метку для заданного FEC. Рассылка меток “вниз по течению” должна учитывать тот факт, что может быть много нижестоящих узлов в заданном дереве для канала с множественным доступом; каждый узел может предложить свою метку для FEC, что потребует некоторого разбирательства, чтобы каждому мультикастному FEC была присвоена лишь одна метка.
Раз метка присвоена, может возникнуть ситуация, когда инициатор возникновения данной метки покинет данное дерево. В случае присвоения меток “вниз по течению”, это может случиться, когда инициатор присвоения покинет группу. В случае присвоения меток “вверх по течению” это может случиться, когда в вышестоящем LSR происходят изменения, сопряженные с вариацией топологии рассылки уникастных сообщений.
