프레임 릴레이 및 ATM을 통한 멀티링크 PPP 설계 및 구축

소개

Cisco IOS® Software Release 12.1(5)T에 Multilink PPP over ATM 및 Multilink PPP over Frame Relay(MLPoATM 및 MLPoFR)가 도입되었습니다. 이 기능은 VoIP(Voice over IP)를 중간 및 저속 WAN 링크에 구축하는 FR/ATM 인터워킹(FR/ATM IW)을 사용하는 고객을 대상으로 합니다. 이 기능 이전에는 ATM과 Frame Relay 고객 모두에서 Cisco IOS가 지원하는 공통 레이어 2 프래그먼트화 구성표가 FR/ATM IW를 사용하는 데 강제적으로 적용되지 않았습니다.

사전 요구 사항

요구 사항

이 문서는 MLPoATM 및 프레임 릴레이 네트워크를 포함하는 VoIP 네트워크의 설계 및 구축에 관여하는 네트워킹 담당자를 대상으로 합니다. 다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• 프레임 릴레이

• ATM

• PPP

• MLP

• 프레임 릴레이/ATM 인터워킹

• QoS(Voice Quality of Service) 컨피그레이션

이 문서는 이러한 주제에 대한 기술 교육을 제공하기 위한 것이 아닙니다. 참고 자료 목록은 이 문서의 끝에 포함되어 있습니다. Cisco에서는 이 문서를 읽기 전에 다음 문서를 검토하고 이해하는 것이 좋습니다.

• QoS(Quality of Service)를 통한 VoIP over Frame Relay(조각화, 트래픽 셰이핑, LLQ/IP RTP 우선순위)

• LLQ, PPP LFI 및 cRTP를 통한 ATM로의 프레임 릴레이를 위한 VoIP QoS

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• MLP over FR/ATM IW용 Cisco IOS Software 릴리스 12.1(5)T 이상

• Cisco IOS Software Release 12.2(2)T 이상 - ATM을 통한 cRTP(Compressed Real Time Transport Protocol)

• 프레임 릴레이를 통한 LLQ(Low Latency Queuing)와 물리적 인터페이스의 ATM용 Cisco IOS Software 릴리스 12.0(7)T

• LLQ over Frame Relay용 Cisco IOS Software 릴리스 12.1(2)T 및 PVC(Permanent Virtual Circuit)당 ATM

이 문서에 포함된 사례 연구는 다음과 같은 소프트웨어 및 하드웨어 버전을 사용하는 프로덕션 네트워크를 기반으로 합니다.

• 코어 Cisco 3660 라우터는 Cisco IOS Software 릴리스 12.2(5.8)T를 실행합니다. cRTP over ATM에 대한 요구 사항은 Cisco IOS Software 릴리스 12.2T를 사용하도록 지시합니다. 이 알려진 문제는 Cisco IOS Software 릴리스 12.2(8)T1에서 해결되었습니다.

  Cisco 버그 ID CSCdw44216(등록된 고객만 해당) - cRTP는 클래스 기반 CBWFQ(Weighted Fair Queuing)/LLQ 링크가 혼잡을 때 높은 CPU를 발생시킵니다.

• 브랜치 Cisco 2620 라우터는 Cisco IOS Software Release 12.2(3)에서 하나의 2.2(6a)로 업그레이드 중입니다. Cisco 2620은 지점 H.323 게이트웨이 역할도 합니다. 업그레이드는 게이트웨이 관련 문제로 인해 트리거됩니다. WAN 및 QoS 기능에 관한 한, Cisco IOS Software 릴리스 12.2(3)에는 중요한 문제가 없습니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

설계

이 섹션에서는 프레임 릴레이 및 ATM을 통한 멀티링크 PPP의 설계 및 구축과 관련된 여러 설계 개념에 대해 설명합니다.

데이터 링크 오버헤드

MLP를 사용하여 ATM 및 프레임 릴레이 네트워크를 설계할 때 데이터 링크 오버헤드를 이해해야 합니다. 오버헤드는 각 VoIP 통화에 사용된 대역폭의 양에 영향을 줍니다. 또한 최적의 MLP 프래그먼트 크기를 결정하는 데에도 도움이 됩니다. 특히 셀 패딩에서 상당한 양의 대역폭이 낭비되는 느린 속도 PVC에서 ATM 셀의 적수에 맞게 프래그먼트 크기를 최적화하는 것이 중요합니다. MLP over Frame Relay 및 ATM PVC의 데이터 링크 오버헤드는 다음 요인에 따라 달라집니다.

• FRF.8 IW 장치의 작동 모드(투명 또는 변환).

• 트래픽의 방향(ATM to Frame Relay 또는 Frame Relay to ATM)입니다.

• PVC 다리 PVC의 ATM과 Frame Relay 레그에는 오버헤드가 다릅니다.

• 트래픽 유형입니다. 데이터 패킷에는 MLP 헤더가 있습니다. VoIP 패킷은 그렇지 않습니다.

이 표에서는 데이터 패킷에 대한 데이터 링크 오버헤드를 보여 줍니다. FRF.8 작동 모드, 트래픽 방향 및 PVC 레그의 모든 변이를 위한 다양한 프레임 릴레이, ATM, LLC, PPP 및 MLP 헤더의 바이트 수를 자세히 설명합니다.

¹ DSAP/SSAP—대상 서비스 액세스 포인트/소스 서비스 액세스 포인트.

² NLPID—네트워크 레이어 프로토콜 식별

변환 PVC는 양쪽 방향에서 오버헤드가 동일하므로 이해하기 쉬운 방법입니다. 이는 FRF.8 디바이스가 MLPoATM과 MLPoFR 형식 간에 변환되기 때문입니다. 따라서 프레임 릴레이 레그의 프레임 형식은 양방향의 MLPoFR입니다. ATM 레그의 형식은 양방향의 MLPoATM입니다.

간접비가 두 방향에서 다르기 때문에 투명한 PVC는 약간 메시아적이다. 프레임 릴레이 라우터가 MLPoFR 형식으로 패킷을 전송하기 때문에 이러한 복잡성이 발생합니다. 이 형식은 IW 디바이스에서 ATM 측면으로 전달됩니다. 마찬가지로 ATM 라우터는 MLPoATM 형식으로 패킷을 전송합니다. 이 형식은 IW 디바이스에서 프레임 릴레이 측면으로 전달됩니다. 따라서 각 레그의 두 방향에서 서로 다른 프레임 형식이 만들어집니다.

이와 달리 FRF.12를 사용하는 엔드 투 엔드 프레임 릴레이 PVC의 오버헤드는 11바이트입니다. 따라서 엔드 투 엔드 프레임 릴레이 링크에서 FRF.12는 MLP보다 링크 프래그먼트화 및 인터리빙(LFI)에 더 효율적인 선택입니다. 엔드 투 엔드 ATM 가상 회로(VC)에서 MLP는 사용 가능한 표준 기반 프래그먼트화가 없기 때문에 유일한 선택 사항입니다. 그러나 엔드 투 엔드 ATM VC는 중간에서 고속으로 작동합니다. 따라서 LFI는 필요하지 않습니다. 이 규칙의 예외 사항은 DSL(Digital Subscriber Line)을 통한 느린 속도 ATM VC입니다.

PPP ID는 첫 번째 MLP 프래그먼트에만 있습니다. 따라서 첫 번째 프래그먼트의 오버헤드는 항상 후속 프래그먼트보다 2바이트입니다.

이 표에서는 VoIP 패킷에 대한 데이터 링크 오버헤드를 보여 줍니다. FRF.8 작동 모드, 트래픽 방향 및 PVC 레그의 모든 변이를 위한 다양한 프레임 릴레이, ATM, LLC 및 PPP 헤더의 바이트 수를 자세히 설명합니다. 데이터와 VoIP 패킷의 주요 차이점은 VoIP 패킷은 MLP 패킷이 아니라 PPP 패킷으로 전송된다는 것입니다. 다른 모든 측면은 데이터 시나리오와 동일합니다.

이와 달리 엔드 투 엔드 프레임 릴레이 PVC의 VoIP 패킷에 대한 데이터 링크 오버헤드는 맨 오른쪽 열에 표시됩니다.

VoIP 대역폭 요구 사항

VoIP에 대한 대역폭을 프로비저닝할 때 데이터 링크 오버헤드를 대역폭 계산에 포함해야 합니다. 이 표에서는 다양한 VoIP 유형에 대한 통화당 대역폭 요구 사항을 보여줍니다. PVC의 특성을 기반으로 합니다. 이 표의 계산은 cRTP에 대한 최상의 시나리오를 가정합니다(예: UDP 체크섬 없음, 전송 오류 없음). 헤더는 40바이트에서 2바이트로 지속적으로 압축됩니다.

오버헤드는 PVC의 서로 다른 다리에 따라 다르므로 최악의 경우에 대비하여 설계해야 합니다. 예를 들어 투명 PVC에서 20ms(msec) 샘플링을 사용하는 G.729와 cRTP를 고려하십시오. 프레임 릴레이 레그에서 이 시나리오의 대역폭 요구 사항은 한 방향으로 12.4Kbps, 다른 방향으로 13.2Kbps입니다. 통화당 13.2Kbps를 가정하면 프로비저닝을 수행해야 합니다.

이와 달리 엔드 투 엔드 프레임 릴레이 PVC의 VoIP 대역폭 요구 사항은 위 표의 맨 오른쪽 열에 나와 있습니다. 네이티브 프레임 릴레이 캡슐화에 비해 PPP의 추가 오버헤드로 인해 통화당 0.5Kbps에서 0.8Kbps 사이의 추가 대역폭 소비가 발생합니다. 따라서 엔드 투 엔드 프레임 릴레이 VC의 MLP보다 FRF.12를 사용한 프레임 릴레이 캡슐화가 더 적합합니다.

참고: cRTP over ATM에는 Cisco IOS Software 릴리스 12.2(2)T 이상이 필요합니다.

조각화 크기 최적화

Frame Relay/ATM PVC에서 MLP를 사용해야 하는 이유는 대용량 데이터 패킷을 더 작은 청크로 분할할 수 있도록 하기 위한 것입니다. 그런 다음 라우터는 데이터 조각 사이에 VoIP 패킷을 인터리빙하여 신속하게 처리합니다. Cisco IOS에서 조각화 크기는 직접 구성되지 않습니다. 대신 ppp multilink fragment-delay 명령의 도움말을 사용하여 원하는 지연을 구성합니다. 그런 다음 Cisco IOS는 다음 공식을 사용하여 적절한 프래그먼트 크기를 계산합니다.

fragment size = delay x bandwidth/8

ATM에서 MLP를 수행할 때 조각 크기를 최적화해야 전체 셀 수에 맞게 조정할 수 있습니다. 이 최적화가 수행되지 않으면 패딩으로 인해 필요한 대역폭이 거의 두 배로 늘어납니다. 예를 들어, 각 프래그먼트의 길이가 49바이트이면 각 프래그먼트를 전달하는 데 두 개의 ATM 셀이 필요합니다. 따라서 106바이트는 49바이트의 페이로드를 전달하는 데 사용됩니다.

Cisco IOS는 MLPoATM 및 MLPoFR을 수행할 때 정수 계열 ATM 셀을 사용하도록 프래그먼트 크기를 자동으로 최적화합니다. Cisco IOS는 계산된 프래그먼트 크기를 ATM 셀의 다음 정수 수까지 자동으로 반올림합니다. 새 CLI 명령이 추가되지 않습니다. Cisco IOS는 MLPoFR/ATM PVC의 프레임 릴레이 및 ATM 끝에서 이 최적화를 수행합니다. MLP PVC는 엔드 투 엔드 프레임 릴레이일 수 있습니다. 이 경우 ATM에 최적화하지 않아도 됩니다. 그러나 Cisco IOS는 원격 끝이 ATM인지 프레임 릴레이인지를 탐지할 방법이 없으므로 ATM에 대해 이 시나리오를 최적화합니다.

참고: 반올림으로 인해 결과가 구성된 것보다 약간 더 높을 수 있습니다. 이 반올림 오류는 저속 PVC에서 더 중요합니다.

최적화를 수동으로 구성할 수도 있습니다. 프래그먼트 크기는 Cisco IOS에서 직접 지정할 수 없으므로 최적의 프래그먼트 크기를 계산하고 지연으로 변환합니다. 프래그먼트 크기를 계산할 때 MLP 코드에서 모든 링크가 HDLC(High-Level Data Link Control)이고 2바이트의 데이터 링크 오버헤드가 있다고 가정할 때 데이터 링크 오버헤드를 조정합니다. HDLC 데이터 링크 오버헤드 외에도 MLP 코드에는 MLP ID로 구성된 8바이트, MLP 시퀀스 번호 및 위의 첫 번째 표에 설명된 PPP ID가 계산에 포함됩니다.

Cisco IOS에서 구성할 지연을 계산하려면 다음 절차를 사용하십시오.

1. 원하는 지연 및 PVC의 대역폭을 기반으로 이론적 프래그먼트 크기를 계산합니다.

   fragment = bandwidth * delay / 8

2. 프래그먼트가 48바이트의 배수인지 확인하고 ATM 셀의 정수 수에 맞아야 합니다.

   셀 정렬 조각 크기를 계산하는 수식은 다음과 같습니다.

   fragment_aligned = (int(fragment/48)+1)*48

3. MLP에서 고려하지 않은 데이터 링크 오버헤드에 대해 조정합니다.

   앞에서 설명한 것처럼 이 오버헤드는 PVC 특성에 따라 다릅니다. PVC의 ATM 측면을 최적화하는 측면으로 간주합니다. 이 표에서는 ATM 측의 데이터 링크 오버헤드의 바이트 수를 보여 줍니다.

   FRF.8 모드	투명		번역
   트래픽 방향	ATM에 프레임 릴레이	ATM-프레임 릴레이	ATM에 프레임 릴레이	ATM-프레임 릴레이
   PVC의 프레임 릴레이 또는 ATM 레그	ATM	ATM	ATM	ATM
   LLC DSAP/SSAP(0xfefe)	0	2	2	2
   LLC 제어(0x03)	1	1	1	1
   NLPID(PPP의 경우 0xcf)	1	1	1	1
   AAL5	8	8	8	8
   비 MLP 오버헤드(바이트)	10	12	12	12

   MLP가 계산을 기반으로 하는 프래그먼트 크기에 도달하려면 원하는 셀 정렬 프래그먼트 크기에서 데이터 링크 오버헤드를 빼십시오. MLP에서 항상 가정하는 HDLC 캡슐화를 보완하려면 2바이트를 다시 추가합니다.

   MLP 코드 대상의 프래그먼트 크기를 계산하는 공식은 다음과 같습니다.

   fragment_mlp = fragment_aligned - datalink_overhead + 2

4. 다음 수식을 사용하여 결과를 해당 지연으로 만드는 조각 크기를 변환합니다.

   delay = fragment_mlp/bandwidth x 8bits/byte

5. 대부분의 경우 계산된 지연은 정수(밀리초)가 아닙니다. Cisco IOS는 정수 값만 허용하므로 반올림해야 합니다. 따라서 ppp multilink fragment-delay 명령의 도움을 받아 Cisco IOS에서 구성하는 지연 값은 다음과 같습니다.

   fragment_delay = int(fragment_mlp/bandwidth x 8bits/byte)

6. 위의 반올림 오류를 보완하기 위해 MLP에서 지연 상태에서 프래그먼트로 변환하는 데 사용되는 대역폭을 퍼핑합니다. Cisco IOS에서 bandwidth 명령의 도움을 받아 구성하는 대역폭은 다음과 같습니다.

   bandwidth = fragment_mlp/fragment_delay * 8

이 표에서는 가장 일반적인 PVC 속도에 대한 ppp multilink fragment-delay 및 대역폭의 최적 값을 보여줍니다. 10msec의 대상 지연으로 간주됩니다. 테이블을 간소화하기 위해 계산에서는 투명 PVC와 변환 PVC를 구별하거나 트래픽 방향을 구분하지 않습니다. 데이터 링크 오버헤드의 최대 차이점은 2바이트입니다. 따라서 최악의 12바이트의 경우 설계할 때의 페널티는 작습니다. 또한 프래그먼트가 필수 셀 수에 맞도록 프래그먼트 크기를 증가시켜 발생하는 "실제" 지연도 표에 나와 있습니다.

트래픽 셰이핑 및 폴리싱 고려 사항

Frame Relay/ATM IW 환경에서 트래픽 셰이핑 및 폴리싱에 대해 특별히 고려해야 합니다. ATM로의 프레임 릴레이 방향에서의 문제는 ATM에서 프레임 릴레이 방향으로의 문제 와 다릅니다. 따라서 각 주제에 대해 별도로 설명합니다.

프레임 릴레이에서 ATM 방향으로의 주요 문제는 프레임에서 셀까지 이동할 때 대역폭 소비의 잠재적인 확장입니다. 예를 들어 프레임 릴레이 측의 49바이트 프레임은 ATM 측에서 두 셀 또는 106바이트를 소비합니다. 따라서 지속 가능한 셀 전송률(SCR)이 CIR(committed information rate)과 같다고 가정할 수 없습니다. 각 프레임 릴레이 프레임에 페이로드 1바이트가 포함된 경우 최악의 시나리오가 발생합니다. 이러한 각 바이트는 ATM 측에서 전체 53바이트 셀을 사용합니다. 이 개념의 예로, 이 극단적이고 비현실적인 시나리오는 CIR의 53배에 달하는 SCR을 제시합니다. 보다 현실적인 두 가지 예는 다음과 같습니다.

• G.729 VoIP 패킷은 60바이트 길이 또는 69바이트(MLP 및 프레임 릴레이 오버헤드가 포함된 경우) ATM 레그에서는 두 셀 또는 106바이트를 소비합니다. 따라서 전송된 모든 트래픽이 VoIP인 경우 적절한 매핑은 SCR = 106/69 = 1.5 x CIR입니다.

• 단일 키 입력을 전달하는 텔넷 패킷에는 40바이트의 TCP/IP 헤더와 1바이트의 데이터가 포함됩니다. Frame Relay(프레임 릴레이) 측면에서는 오버헤드를 포함하여 총 56바이트입니다. 그러나 ATM 측에서 이 패킷은 두 개의 셀로 확장됩니다. 이 경우 SCR = 106/56 = 1.9 x CIR

ATM Forum 표준의 부록 A, B-ICI(Inter Carrier Interface) Specification Version 2.0은 SCR과 CIR 간의 매핑 두 가지 방법에 대해 설명합니다. 둘 다 CIR에서 SCR을 파생시키는 과학적 방법을 제공하지만, 둘 중 어느 것도 CIR이 적용된 데이터보다 정확하지는 않습니다. 수식에 필요한 숫자 중 하나는 일반적인 프레임 크기인 실제 네트워크에서 결정하기 어려운 숫자입니다. 또한 기존 ATM/Frame Relay 네트워크에서 새로운 애플리케이션이 배포됨에 따라 변경될 수 있는 숫자입니다. 이 문제를 해결하기 위한 최선의 권장 사항은 해당 회사의 정책 정책이 매우 중요하므로 해당 통신사와 긴밀하게 협력하는 것입니다. 운송업체의 도움을 받아 이 fail-safe 접근 방식은 다음과 같습니다.

• ATM 방향으로의 프레임 릴레이 - ATM 방향으로의 프레임 릴레이에서 통신사는 프레임 릴레이 인그레스 지점에서만 인바운드 트래픽을 감시해야 합니다. 예를 들어, CPE(Frame Relay attached customer premises equipment) 디바이스에 연결된 Frame Relay 스위치에서 통신사는 계약된 CIR에 따라 트래픽을 정책합니다. 이 경찰 정책은 여기 그림에 나와 있다. 인그레스 지점에서 네트워크로 트래픽이 허용되면 더 이상 폴리싱이 발생하지 않아야 합니다. 이 정책 정책의 의미는 프레임 릴레이 측에서 수신된 데이터가 네트워크의 ATM 레그를 통해 이를 전달하기 위해 셀 세금, AAL 오버헤드 및 패딩에 필요한 대역폭을 확장하고 소비할 수 있다는 것입니다. 대부분의 경우 필요한 ATM 대역폭은 사용된 프레임 릴레이 대역폭의 두 배 미만입니다.

  

• ATM to Frame Relay Direction - ATM to Frame Relay 방향에서는 반대쪽 방향입니다. ATM에서 프레임으로 이동하면서 셀 세금, AAL 오버헤드, 패딩 제거 시 대역폭 사용량이 감소합니다. 그러나 ATM 측의 잠재적인 전송 속도가 Frame Relay 링크의 전송 속도보다 훨씬 높으므로 ATM 라우터에서 트래픽 셰이핑을 올바르게 설정하는 것은 음성의 무결성을 위해 중요합니다. 셰이핑이 너무 느슨하면 ATM 라우터는 다른 쪽 끝에 있는 Frame Relay 링크의 실제 속도보다 빠른 속도로 데이터를 제공합니다. 따라서 패킷이 FRF.8 스위치에서 대기하기 시작합니다. 어느 시점에서는 패킷이 삭제되기 시작합니다. ATM/Frame Relay 네트워크는 음성과 데이터를 구분하지 않으므로 VoIP 패킷도 삭제됩니다.

  동시에 쉐이핑이 너무 제한적이면 처리량이 저하됩니다. ATM 셀 세금 때문에 AAL 오버헤드와 패딩은 FRF.8 장치에서 제거됩니다. Frame Relay 링크에서는 대역폭을 사용하지 않습니다. 따라서 PVC의 ATM 측면을 약간 오버서브스크립션할 수 있습니다. 패딩 및 AAL 오버헤드의 양은 평균 프레임 크기와 프래그먼트화가 얼마나 적극적인지에 따라 달라집니다. 이 오버헤드를 정확하게 검증할 수 없으므로 최적화를 시도하지 않는 것이 좋습니다. 반면 세포세는 완전하다. 페이로드의 48바이트당 5바이트입니다. ATM 라우터의 쉐이핑 대상을 53/48 x SCR로 설정하여 셀세를 최적화할 수 있습니다. 이 약간의 초과 가입을 허용하려면 통신업체 측의 폴리싱을 설정해야 합니다.

힌트 및 주의 사항

• MLPoATM/Frame Relay는 현재 가상 템플릿 또는 다이얼러 인터페이스에 연결된 서비스 정책에서만 테스트되고 지원됩니다. 서비스 정책을 생략하면 기능이 작동하지 않을 수 있습니다. 이 예제 중 하나는 Cisco 버그 ID CSCdu19313에 설명되어 있습니다(등록된 고객만 해당).

• MLPoATM/Frame Relay는 각 PVC에 대해 두 개의 가상 액세스 인터페이스를 복제합니다. 이 중 하나는 PPP 링크를 나타냅니다. 다른 하나는 MLP 번들을 나타냅니다. show ppp multilink 명령을 사용하여 어떤 명령인지 확인합니다. 번들당 여러 PPPoFR 링크는 지원되지 않습니다. PPPOFR 드라이버는 실제 직렬 드라이버에 대한 흐름 제어 신호를 제공하지 않으므로, 두 개의 PPPOFR 회로를 하나의 번들 트래픽에 넣어도 회로에서 부하가 잘 분산되지 않습니다. ATM 또는 프레임 릴레이를 통한 MLPPP 로드 밸런싱은 물리적 인터페이스에 대해 동일한 로드 밸런싱보다 훨씬 덜 효과적일 수 있습니다.

• 각 PVC는 물리적 인터페이스, 하위 인터페이스, 2개의 가상 액세스 인터페이스 등 4개의 서로 다른 인터페이스와 연결됩니다. MLP 가상 액세스 인터페이스만 화려한 큐잉이 활성화되었습니다. 나머지 3개의 인터페이스에는 먼저 FIFO(first out) 큐잉이 있어야 합니다.

• service-policy 명령을 가상 템플릿에 적용하면 Cisco IOS는 다음과 같은 일반 경고 메시지를 표시합니다.

  cr7200(config)#interface virtual-template 1
  cr7200(config-if)#service-policy output Gromit
  Class Based Weighted Fair Queueing (CBWFQ) not supported on interface Virtual-Access1
  Note CBWFQ supported on MLP bundle interface only.
  

  이러한 메시지는 정상입니다. 첫 번째 메시지는 서비스 정책이 PPP 가상 액세스 인터페이스에서 지원되지 않음을 알려줍니다. 두 번째 메시지는 서비스 정책이 MLP 번들 가상 액세스 인터페이스에 적용되었음을 확인합니다. 이 팩트는 show interfaces virtual-access, show queue 및 show policy-map interface 명령의 도움을 받아 대기열 메커니즘을 확인할 수 있습니다.

• PVC는 임대 회선과 유사하므로 PPP 인증이 엄격하게 필요하지 않습니다. 그러나 show ppp multilink 명령을 사용하여 PVC의 반대쪽 끝에 있는 라우터의 이름을 결정하면 PPP 인증이 편리합니다.

• 프레임 릴레이 라우터의 MLPoFR PVC에 대해 프레임 릴레이 트래픽 셰이핑을 활성화해야 합니다.

• Cisco IOS Software Release 12.2는 처음에 라우터당 최대 25개의 가상 템플릿을 지원했습니다. 이러한 제한은 각 PVC에 고유한 IP 주소가 필요한 경우 ATM 배포 라우터의 규모에 영향을 줄 수 있습니다. 영향을 받는 버전에 대한 해결 방법은 IP 번호가 지정되지 않은 인터페이스를 사용하거나 가상 템플릿 대신 다이얼러 인터페이스를 사용하는 것입니다. Cisco IOS Software Release 12.2(8)T에서 지원이 200개의 가상 템플릿으로 증가합니다.

• 일부 통신 사업자는 FRF.8 디바이스에서 PPP 변환을 아직 지원하지 않습니다. 이러한 제한이 적용될 때마다 공급자는 투명 모드에 대해 PVC를 구성해야 합니다.

• Cisco IOS 설명서의 대부분의 예에는 프레임 릴레이 또는 ATM 하위 인터페이스가 포함된 컨피그레이션이 나와 있습니다. 이 하위 인터페이스는 아무런 용도가 없습니다. 가상 템플릿은 물리적 인터페이스에 연결하기만 하면 됩니다. 그 결과, 보다 작고 관리가 용이한 구성이 만들어집니다. 이는 PVC가 많은 경우 특히 중요합니다.

• show ppp multilink 명령을 fail-proof 방법으로 사용하여 캐리어 측에 셀/프레임 드롭이 있는지 확인합니다. 허용되는 프래그먼트 손실은 CRC(cyclic redundancy check) 오류로 인한 것입니다.

• MLPoATM/Frame Relay가 Cisco IOS Software Release 12.1(5)T에 소개되었지만, 이 및 후속 릴리스의 버그에 따라 Cisco IOS Software Release를 선택할 때 주의해야 할 사항이 결정됩니다. Cisco는 Cisco IOS 12.2 메인스트림(Mainstream)의 최신 유지보수 릴리스를 사용하는 것이 좋습니다. 그러나 다른 VoIP 기능 요구 사항은 SRST(Survivable Remote Site Telephony)가 필요한 경우 12.2(2)XT와 같은 다른 Cisco IOS Software 릴리스의 사용을 지시할 수 있습니다. 이 표에는 몇 가지 알려진 문제가 나열되어 있습니다. Cisco IOS를 선택하면 각 Cisco 버그 ID가 선택한 IOS에 대해 평가되어야 합니다.

사례 연구

소개

이 섹션에서는 MLPoATM/프레임 릴레이 기능의 첫 번째 고객 구축 중 하나에 대해 설명합니다. 이 고객은 가상의 이름인 XYZ Ltd.에서 참조됩니다. 2001년, XYZ Ltd는 PBX를 IP 텔레포니 솔루션으로 교체했습니다. 이 프로젝트의 일환으로 새로운 IP 네트워크가 구축되었습니다. WAN을 위해 Frame Relay/ATM 상호 운용이 선택되었습니다. WAN 서비스를 제공하는 캐리어는 Newbridge 스위치를 사용하여 ATM 및 Frame Relay 서비스를 제공합니다.

네트워크 개요

XYZ Ltd 네트워크는 26개의 지사를 2개의 코어 사이트와 연결하는 허브 및 스포크 네트워크입니다. 각 코어 사이트는 Cisco 3660 라우터에 연결된 E3 ATM에서 제공합니다. 26개 지점 중 18개는 중간 사이즈이다. ATM/Frame Relay IW를 통해 두 코어 사이트의 3660에 다시 연결되는 듀얼 프레임 릴레이 PVC가 있습니다. 나머지 8개 지점은 매우 작습니다. 단일 프레임 릴레이 PVC를 통해 가장 가까운 중간 크기의 브랜치에 다시 연결됩니다. 모든 브랜치 라우터는 Cisco 2620입니다. 엔드 투 엔드 ATM PVC는 두 허브 사이트에 있는 두 3660 라우터를 연결합니다. 이 그림은 토폴로지를 보여줍니다.

이 표에서는 프레임 릴레이 액세스 속도와 CIR을 보여 줍니다. CIR은 32kbps에서 256kbps까지 다양합니다. 또한 각 PVC에서 수행한 최대 동시 VoIP 통화 수입니다.

프레임 릴레이 트래픽 셰이핑은 브랜치 라우터에서 수행합니다. CIR을 초과하는 버스팅이 허용됩니다. Cisco IOS 트래픽 셰이핑은 CIR과 같은 최소 속도로 액세스 속도에 맞게 조정되도록 설정됩니다. 캐리어로부터 역방향 BECN(Explicit Congestion Notification)을 수신하면 라우터가 다시 mincir로 조절됩니다. 이러한 접근 방식은 VoIP over Frame Relay를 수행할 때 Cisco의 권장 사항에 맞지 않습니다. 라우터가 혼잡 알림에 응답했을 때 음성 문제가 이미 발생했습니다. 그러나 이 경우 캐리어는 네트워크가 충분히 프로비저닝되어 프레임 또는 셀을 삭제하지 않으므로 BECN을 볼 수 없습니다.

ATM 트래픽 셰이핑은 원격 끝의 프레임 액세스 속도와 셀 세금에 맞게 조정되도록 설정됩니다. 예를 들어, 액세스 속도가 512Kbps이면 SCR은 512x53/48 = 565Kbps로 설정됩니다. 이 쉐이핑 속도는 처리량을 최대화하는 데 사용됩니다. 이것은 IW점에서 셀 세금이 삭감되기 때문에 안전하다. 통신 사업자 측의 폴리싱은 약간 초과 서브스크립션이 허용되도록 많이 구성됩니다.

cRTP는 WAN에서 사용됩니다. CPU에 관한 한 Cisco 3660 디스트리뷰션 라우터는 코어 사이트 1의 Cisco 3660 디스트리뷰션 라우터입니다. 위 표에 숫자를 추가하여 이 라우터를 통과하는 이론상 최대 VoIP 통화 수는 102건이라고 판단됩니다. 이 그래프의 성능 수치는 100cRTP 세션(고속 스위치드)에 대한 Cisco 3660 CPU 로드가 약 50%임을 나타냅니다.

가상 템플릿은 IP 번호 WAN 링크와 함께 사용됩니다. 각 Cisco 3660에서 종료되는 총 PVC 수가 25개 미만이므로 PVC당 하나의 가상 템플릿이 필요합니다.

구성

이 문서에서는 다음 구성을 사용합니다.

• 코어 ATM 라우터

• 브랜치 프레임 릴레이 라우터

!--- Note: This section shows the parts of a core Cisco 3660 router !--- configuration that is relevant to MLPoATM.

        
class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map toortr01
  class Voice_Stream
    priority 175
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.105 255.255.255.252

interface ATM2/0
 description To Carrier E3 ATM Service
 no ip address

interface ATM2/0.15 point-to-point
 pvc toortr01 0/58 
  vbr-nrt 406 406
  tx-ring-limit 8
  protocol ppp Virtual-Template15

interface Virtual-Template15
 bandwidth 320
 ip unnumbered loopback0
 ip tcp header-compression iphc-format
 service-policy output toortr01
 ppp multilink
 ppp multilink fragment-delay 14
 ppp multilink interleave
 ip rtp header-compression iphc-format


!--- Note: Do not configure !--- IP addresses directly on any configuration source, !--- such as a virtual template, whenever the possibility !--- exists that this information is cloned to multiple !--- active interfaces. The exception to this rule is the !--- rare case where the intent is to define multiple parallel !--- IP routes and have IP do load balancing between them. !--- If an IP address is present on the configuration source, !--- this IP address is copied to all the cloned interfaces. !--- IP installs a route to each of these interfaces.
 

!--- Note: This section shows the parts of a branch Cisco 2600 router !--- configurations that is relevant to MLPoFR.


class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map dhartr21
  class Voice_Stream
    priority 240
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.106 255.255.255.252

interface Serial0/0
 description To Carrier Frame Relay Service
 encapsulation frame-relay IETF
 frame-relay traffic-shaping

interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 38 ppp Virtual-Template1
  class dhartr21

interface Virtual-Template1
 bandwidth 320
 ip unnumbered loopback0
 max-reserved-bandwidth 85
 service-policy output dhartr21
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave

map-class frame-relay dhartr21
 frame-relay adaptive-shaping becn
 frame-relay cir 320000
 frame-relay bc 3200
 frame-relay mincir 320000

관련 정보

• QoS(Quality of Service)를 통한 VoIP over Frame Relay(조각화, 트래픽 셰이핑, LLQ/IP RTP 우선순위)
• LLQ, PPP LFI 및 cRTP를 통한 ATM로의 프레임 릴레이를 위한 VoIP QoS
• 프레임 릴레이 및 ATM 가상 회로에 대한 링크 조각화 및 인터리빙 구성
• PPP Over AAL5, RFC 2364, 1998년 7월
• PPP in Frame Relay, RFC1973, 1996년 6월
• PPP MP(Multilink Protocol), RFC 1717, 1994년 11월
• 저속 직렬 링크의 IP/UDP/RTP 헤더 압축, RFC 2508, 1999년 2월
• Frame Relay / ATM PVC Service Interworking Implementation Agreement FRF.8.2
• 프레임 릴레이 조각화 구현 계약 FRF.12
• 음성 기술 지원
• 음성 및 IP 커뮤니케이션 제품 지원
• Cisco IP 텔레포니 문제 해결
• 기술 지원 및 문서 − Cisco Systems