Примеры сетевых топологий

         

Ссылки


[DSS1]ITU-T Recommendation, "Digital subscriber Signaling System No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control", Rec. Q.931(I.451), May 1998
[KPS]

Kaufman, C., Perlman, R., и Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1

[RFC791]Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC1034]Mockapetris, P., "Domain Names - Concepts и Facilities", STD 13, RFC 1034, November 1987.
[RFC1144]Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1661]Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1662]Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1663]Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[RFC1700]

Reynolds, J. и J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. Смотри также: http://www.iana.org/numbers.html

[RFC1990]

Sklower, K., Lloyd, B., McGregor, G., Carr, D. и T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

[RFC1994]Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1918]

Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. и E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2138]

Rigney, C., Rubens, A., Simpson, W. и S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.

[RFC2277]Alvestrand, H., "IETF Policy on Character Sets и Languages", BCP 18, RFC 2277, January 1998.
[RFC2341]Valencia, A., Littlewood, M. и T. Kolar, "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2401]Kent, S. и R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2434]

Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[RFC2637]

Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. и G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.

[STEVENS]

Stevens, W. Richard, "TCP/IP Illustrated, Volume I The Protocols", Addison-Wesley Publishing Company, Inc., March 1996, ISBN 0-201-63346-9

<
/p>
Приложение A:Медленный старт в управляющем канале и подавление перегрузки


Хотя каждая из сторон указала максимальный размер окна приема, рекомендуется, чтобы при передаче управляющих пакетов использовался медленный старт и метод подавления перегрузки. Методы, описанные здесь, базируются на TCP-алгоритме подавления перегрузки, как это описано в разделе 21.6 книги “TCP/IP Illustrated”, том I, написанной W. Richard Stevens [STEVENS].

Медленный старт и подавление перегрузки используют несколько переменных. Окно перегрузки (CWND) определяет число пакетов, которые отправитель может послать, не дожидаясь подтверждения. Размер CWND расширяется и сокращается так, как это описано ниже. Заметим, однако, что CWND никогда не должно превышать размера окна, полученного из AVP приемного окна (далее предполагается, что любое увеличение ограничивается размером приемного окна). Переменная SSTHRESH определяет, когда отправитель переходит от медленного старта к подавлению перегрузки. Медленный старт используется, когда CWND меньше SSHTRESH.

Отправитель начинает работу с фазы медленного старта. Начальный размер CWND равен одному пакету, а уровень SSHTRESH в начальный момент определяется размером окна (полученным из AVP приемного окна). Отправитель передает один пакет и ждет подтверждения получения. Когда подтверждение получено, окно перегрузки увеличивается на единицу и становится равным двум. Во время медленного старта, размер CWND увеличивается на единицу при получении каждого ACK. Увеличение CWND на 1 при получении ACK приводит к удвоению CWND за время RTT, что эквивалентно экспоненциальному росту. Когда значение CWND достигает SSHTRESH, фаза медленного старта завершается и начинается подавление перегрузки.

При подавлении перегрузки, CWND расширяется более медленно. В частности, оно увеличивается на 1/CWND для каждого полученного подтверждения ACK. Расширение окна на фазе подавления перегрузки является линейным, с увеличением CWND на 1 за время RTT.

Когда происходит перегрузка (индицируемая повторной передачей пакета) половина CWND записывается в SSTHRESH, а CWND делается равным 1.


Отправитель после этого возвращается в режим медленного старта.

Приложение B: Примеры управляющих сообщений

B.1: Установление туннеля Lock-step

В этом примере, LAC формирует туннель, при этом реализуется обмен сообщениями в обоих направлениях. В этом примере показано, что окончательное подтверждение посылается в сообщении ZLB ACK. Альтернативой может быть подтверждение, пришедшее в сообщении, посланном в ответ на ICRQ или OCRQ, которые направляются стороной, инициировавшей формирование туннеля.

LAC или LNSLNS или LAC
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ZLB
Nr: 2, Ns: 1


B.2: Потеря пакета и повторная передача

Существующий туннель имеет новую сессию, запрошенную LAC. Пакет ICRP потерян и должен быть послан LNS повторно. Заметим, что потеря ICRP несет в себе две проблемы: это не только блокирует машину состояний высокого уровня, но и лишает LAC своевременного прихода подтверждения его ICRQ на нижнем уровне.

LAC LNS
ICRQ ->
Nr: 1, Ns: 2
(пакет потерян)<- ICRP
Nr: 3, Ns: 1
(пауза; таймер LAC запускается первым, поэтому первым и срабатывает)
ICRQ ->
Nr: 1, Ns: 2

(Понимая, что он уже видел этот пакет, LNS отбрасывает его и посылает ZLB)
<- ZLB
Nr: 3, Ns: 2
(срабатывает таймер повторной передачи LNS)
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ZLB
Nr: 4, Ns: 2



Содержание раздела