문제

PPP 등 데이터링크 수준의 표준을 살펴보면 일반 프레임 형식 또는 이더넷, 체크섬이 유효하지 않으면 어떤 일이 발생하는지 명확하지 않습니다. 프로토콜은 다음 프레임이 시작되는 위치를 어떻게 알 수 있나요?

(PPP의 경우) 다음 "플래그" 발생만 검색합니까?그렇다면 패킷 페이로드에 우연히 "플래그" 자체가 포함되면 어떻게 될까요?요점은 패킷 프레이밍 필드를 사용하든 "길이" 필드를 사용하든 "길이" 필드가 손상되었거나 "프레이밍" 바이트가 패킷의 일부가 될 수 있는 잘못된 패킷을 복구하는 방법이 명확하지 않다는 것입니다. 패킷 페이로드.

업데이트:나는 "GFP CRC 기반 프레이밍"을 검색하여 내가 찾고 있던 것(엄격히 내가 질문한 내용은 아님)을 찾았습니다.에 따르면 통신 네트워크

GFP 수신기는 3가지 상태 프로세스를 통해 GFP 프레임 경계와 동기화됩니다.수신기는 처음에 사냥 상태 여기서 처음 2바이트에 대해 계산된 CRC가 다음 2바이트의 내용과 같은지 확인하기 위해 한 번에 4바이트를 검사합니다.일치하는 항목이 없으면 GFP는 물리 계층에서 제공하는 옥텟 동기 전송을 가정하므로 GFP는 1바이트 앞으로 이동합니다.수신기가 일치하는 항목을 찾으면 다음 위치로 이동합니다. 사전 동기화 상태.이 중간 상태에서 수신기는 임시 PLI(페이로드 길이 표시기) 필드를 사용하여 다음 프레임 경계의 위치를 ​​결정합니다.목표번호인 경우 N 성공적인 프레임 감지가 달성되면 수신기는 동기화 상태.동기화 상태는 수신기가 각 PLI를 검사하고 cHEC(Core Header Error Checking)를 사용하여 유효성을 검사한 후 페이로드를 추출하고 다음 프레임으로 진행하는 정상적인 상태입니다.

즉, 각 패킷은 "length"와 "CRC(length)"로 시작됩니다.어떤 문자도 이스케이프 처리할 필요가 없으며 패킷 길이는 미리 알려져 있습니다.

패킷 프레이밍에는 두 가지 주요 접근 방식이 있는 것 같습니다.

  • 인코딩 체계(비트/바이트 스터핑, 맨체스터 인코딩, 4b5b, 8b10b 등)
  • 수정되지 않은 데이터 + 체크섬(GFP)

전자가 더 안전하고 후자가 더 효율적입니다.페이로드에 유효한 패킷이 포함되어 있고 라인 손상으로 인해 진행 바이트에 "프레임 시작" 바이트 시퀀스가 ​​포함된 경우 두 가지 모두 오류가 발생하기 쉽지만 그럴 가능성은 거의 없습니다.GFP의 견고성에 대한 확실한 숫자를 찾는 것은 어렵지만 많은 최신 프로토콜이 이를 사용하는 것으로 보이므로 자신이 수행하는 작업을 알고 있다고 가정할 수 있습니다.

도움이 되었습니까?

해결책

당신은 이미 정답에 꽤 가까워졌습니다.기본적으로 프리앰블로 시작하여 체크섬과 일치하는 것으로 끝나면 프레임이 되어 상위 레이어로 전달됩니다.

PPP와 이더넷은 모두 다음 프레임 시작 신호를 찾습니다.이더넷의 경우 이는 64개의 교번 비트 시퀀스인 프리앰블입니다.이더넷 디코더가 그것을 본다면, 뒤따르는 것이 프레임이라고 간단히 가정합니다.비트를 캡처한 다음 체크섬이 일치하는지 확인하여 유효한 프레임이 있는지 결정합니다.

FLAG가 포함된 페이로드의 경우 PPP에서는 이러한 오해를 방지하기 위해 추가 바이트로 이스케이프됩니다.

다른 팁

PPP와 이더넷 모두 프레이밍(framing) 메커니즘을 가지고 있습니다. 즉, 비트 스트림을 프레임으로 나누는 메커니즘을 통해 수신기가 내용을 추적하지 못하는 경우 다음 프레임 시작 시 이를 선택할 수 있습니다.이는 프로토콜 스택의 맨 아래에 있습니다.프로토콜의 다른 모든 세부 사항은 프레임 아이디어를 기반으로 구축되었습니다.특히 프리앰블, LCP, FCS는 더 높은 레벨에 있으며, ~ 아니다 프레임을 제어하는 ​​데 사용됩니다.

전화 접속과 같은 직렬 링크를 통한 PPP는 다음을 사용하여 프레임됩니다. HDLC와 유사한 프레이밍.플래그 시퀀스라고 하는 바이트 값 0x7e는 프레임의 시작을 나타냅니다.프레임은 다음 플래그 바이트까지 계속됩니다.프레임 내용에서 플래그 바이트가 발생하면 이스케이프됩니다.이스케이프는 제어 이스케이프 바이트로 알려진 0x7d를 작성하고 그 뒤에 이스케이프할 바이트를 0x20으로 xor'd 작성하여 수행됩니다.플래그 시퀀스는 0x5e로 이스케이프됩니다.제어 이스케이프 자체도 0x5d로 이스케이프되어야 합니다.다른 값이 존재하면 모뎀이 문제가 될 경우 이스케이프할 수도 있습니다.결과적으로 수신기가 동기화를 잃으면 0x7e가 표시될 때까지 바이트를 읽고 버릴 수 있으며, 이 시점에서 다시 프레임 시작에 있음을 알 수 있습니다.그런 다음 프레임의 내용은 실제로 중요하지는 않지만 PPP 패킷(프로토콜 데이터 단위, PDU라고 함) 및 프레임 검사와 함께 이전 IBM 프로토콜에서 유지되는 몇 가지 이상한 작은 필드를 포함하여 구조화됩니다. 시퀀스(FCS).

이더넷은 데이터가 아닌 프레임 시작 및 끝 마커로 인식할 수 있는 기호를 갖는 논리적으로 유사한 접근 방식을 사용하지만 예약된 바이트와 이스케이프 메커니즘을 사용하는 대신 구별되는 특수 제어 기호를 표현할 수 있는 코딩 방식을 사용합니다. 데이터 바이트에서 - 일련의 문자를 분리하기 위해 구두점을 사용하는 것과 비슷합니다.사용되는 시스템의 세부 사항은 속도에 따라 다릅니다.

표준(10Mb/s) 이더넷은 다음을 사용하여 인코딩됩니다. 맨체스터 인코딩, 전송될 각 비트는 라인에서 두 개의 연속 레벨로 표시됩니다. 이러한 방식으로 모든 비트의 레벨 간에 항상 전환이 있어 수신기가 동기화를 유지하는 데 도움이 됩니다.프레임 경계는 인코딩 규칙을 위반하여 표시되며 전환이 없는 비트가 발생합니다(몇 년 전에 책에서 읽었지만 온라인에서 인용문을 찾을 수 없습니다. 이에 대해 틀렸을 수도 있습니다).실제로 이 시스템은 이진 코드를 0, 1, 위반이라는 세 가지 기호로 확장합니다.

고속(100Mb/s) 이더넷은 다음을 기반으로 하는 다른 코딩 방식을 사용합니다. 5b/4b 코드, 여기서 4개의 데이터 비트(니블) 그룹은 회선에서 5개의 비트 그룹으로 표시되고 맨체스터 방식 없이 직접 전송됩니다.5비트로 확장하면 빈번한 레벨 전환 요구 사항을 충족하는 데 사용되는 16개의 필수 패턴을 선택할 수 있으며, 이는 다시 수신기가 동기화를 유지하는 데 도움이 됩니다.그러나 전송될 수 있지만 데이터 값에 해당하지 않는 일부 추가 기호를 선택할 여지가 여전히 있습니다. 실제로 니블 세트를 24개 기호(니블 0에서 F까지, 그리고 Q, I라는 기호)로 확장합니다. , J, K, T, R, S 및 H.이더넷은 JK 쌍을 사용하여 프레임 시작을 표시하고 TR을 사용하여 프레임 끝을 표시합니다.

기가비트 이더넷은 고속 이더넷과 유사하지만 코딩 방식이 다릅니다. 광섬유 버전은 8b/10b 코드 5b/4b 코드 대신에 트위스트 페어 버전은 제가 실제로 이해하지 못하는 매우 복잡한 5진법 코드 배열을 사용합니다.두 접근 방식 모두 동일한 결과를 산출합니다. 즉, 데이터 바이트 또는 추가 특수 기호의 작은 세트 중 하나를 전송하는 기능이며 이러한 특수 기호는 프레이밍에 사용됩니다.

이 기본 프레이밍 구조 위에는 고정된 프리앰블과 프레임 구분 기호, 그리고 무의미한 다양한 제어 필드(안녕하세요, LLC/SNAP!)가 있습니다.이러한 필드의 유효성은 프레임의 유효성을 검사하는 데 사용할 수 있지만 자체적으로 프레임을 정의하는 데 사용할 수는 없습니다.

내가 아는 한, PPP는 오류 감지만 지원하고 어떤 형태의 오류 수정이나 복구도 지원하지 않습니다.

Cisco에서 백업: http://www.cisco.com/en/US/docs/internetworking/technology/handbook/PPP.html

이것 Wikipedia PPP 라인 활성화 섹션에서는 RFC 1661의 기본 사항을 설명합니다.프레임 검사 시퀀스는 프레임의 전송 오류를 감지하는 데 사용됩니다(이전 캡슐화 섹션에서 설명).

이 Wikipedia 페이지에 있는 RFC 1661의 다이어그램은 오류 발생 시 링크 설정을 통해 네트워크 프로토콜 단계를 다시 시작할 수 있는 방법을 설명합니다.


또한 Suvesh가 참조한 Cisco 페이지의 참고 사항입니다.

PPP 링크 제어 프로토콜

PPP LCP는 지점간 연결을 설정, 구성, 유지 및 종료하는 방법을 제공합니다.LCP는 네 가지 단계를 거칩니다.

먼저 링크 설정 및 구성 협상이 발생합니다.네트워크 계층 데이터그램(예: IP)을 교환하려면 먼저 LCP가 연결을 열고 구성 매개변수를 협상해야 합니다.구성 승인 프레임이 전송되고 수신되면 이 단계가 완료됩니다.

그 다음에는 링크 품질이 결정됩니다.LCP는 링크 설정 및 구성 협상 단계 이후 선택적 링크 품질 결정 단계를 허용합니다.이 단계에서는 링크 품질이 네트워크 계층 프로토콜을 불러올 만큼 충분한지 확인하기 위해 링크를 테스트합니다.이 단계는 선택 사항입니다.LCP는 이 단계가 완료될 때까지 네트워크 계층 프로토콜 정보의 전송을 지연할 수 있습니다.

이 시점에서 네트워크 계층 프로토콜 구성 협상이 발생합니다.LCP가 링크 품질 결정 단계를 마친 후 네트워크 계층 프로토콜은 해당 NCP에 의해 별도로 구성될 수 있으며 언제든지 활성화 및 종료될 수 있습니다.LCP가 링크를 닫으면 적절한 조치를 취할 수 있도록 네트워크 계층 프로토콜에 알립니다.

마지막으로 링크 종료가 발생합니다.LCP는 언제든지 링크를 종료할 수 있습니다.이는 일반적으로 사용자의 요청에 따라 수행되지만 캐리어 손실 또는 유휴 기간 타이머 만료와 같은 물리적 이벤트로 인해 발생할 수 있습니다.

세 가지 클래스의 LCP 프레임이 존재합니다.링크 설정 프레임은 링크를 설정하고 구성하는 데 사용됩니다.링크 종료 프레임은 링크를 종료하는 데 사용되고, 링크 유지 프레임은 링크를 관리하고 디버깅하는 데 사용됩니다.

이러한 프레임은 각 LCP 단계의 작업을 수행하는 데 사용됩니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top